anynines ran a public PaaS located in a German datacenter based on Cloud Foundry. In more than 12 months of running a Cloud Foundry PaaS man lessons about security, high availability, open stack and many other exciting topics have been learned. See how Bosh can be used and how it shouldn't be used. Learn how to perform Cloud Foundry upgrades and read how to harden Cloud Foundry by adding more fault tolerance with pacemaker.
3. • Receive an opinion about running Cloud
Foundry (CF)
• How to shoot your own leg with CF and
overcommitment settings
• How to perform CF updates
• How to harden CF
• Wise words about CF services
24. • Removing a DEA
→ Apps will be evacuated
→ DEA will be stopped
• Bosh deployment will fail when
evacuation takes longer than the Bosh
timeout
• Set your Bosh timeout accordingly!
38. • Create 2nd resource pool for new DEAs
• Deploy the 2nd resource pool before
startup to stop old DEAs
• (-) Needs more resources
• (+) Smoother transition
54. • Monitor VM
• Re-Build VMs automatically
• e.g. using Cloud Foundry Bosh
• + Easy
• - Takes long (minutes not seconds)
• - Open Stack doesn’t release persistent
disks automatically
57. • Build disjunct networks, racks, etc.
• Each disjunct zone = availability zone
• Tell your IaaS about availability zones
• On provision choose the AZ
• Build Bosh releases accordingly
58. • Provide stand-by VM
• Monitor VM and perform failover
• IP failover using Pacemaker
• + Fast failover (seconds)
• - Pacemaker not easy to use (& boshify)
• - Increased resource usage by stdby
VM(s)
59. • 2 * UAA
• 2 * CC
• 2 * n * DEAs
• 2 * Health Manager
• …
62. • UAA and Cloud Controller database
• Single point of failure for Cloud Foundry
63. • Postgres not inherently clusterable >
failover with standby vm
• Master/slave replication
• Pacemaker/corosync
• IP-Failover using NIC-reattachment
73. • Use clusterable services if possible
• Implement automatic failover if not
• Autoprovisioning using Bosh
• Organize self-healing
• (Semi-)Automatic recovery from
degraded mode