ment. As mentioned above, additional capacity must be (over)provisioned in order to ensure sufficient VF capacity to tolerate simultaneous planned and unplanned site outages. In fact, as the number of redundant sites increases in the N+2 deployment scenario, the total preconfigured capacity required decreases by the ratio N/(N-2) for N > 3. That is, in a 3-site scenario, the total required capacity = 3/(3-2) = 300%; in a 4-site scenario, 200%; in a 5-site scenario, 167%, etc. As shown in Figure 5.7, the "sweet spot" in terms of (over)provisioned capacity is in the 4-6 site range (subject to latency constraints). 5.2.2 BEST DESIGN PRACTICES FOR MINIMIZING THE IMPACTS OF PLANNED DOWNTIME As demonstrated above, planned downtime can have a significant impact on VF availability. With this in mind, several common-sense "best practice" guidelines should be considered: Each site should support multiple compute node clusters, often called availability zones, in distinct racks and served by different switches. These availability zones can be used by tenants to achieve local site redundancy through anti-affinity capabilities (Amazon, 2016). The infrastructure should provide L2/L3 connectivity between the availability zones SO that tenant applications can exchange heartbeats, transaction/session state data, etc. Minor upgrades that impact compute nodes (host OS, guest OS, compute/networking vir- tualization software, etc.) should be performed one availability zone at a time. All upgrade and rollback procedures should be thoroughly system tested before being exe- cuted in a production environment. Sites should be assigned to an upgrade group (A, B, C,...), and planned upgrades should be done in a rolling manner such that A sites, B sites, C sites, are not upgraded at the same time. A minimum gap should be allowed between the completion of upgrades in one site group and the start of upgrades in next site group in order to provide stateful tenant applications adequate time to move traffic back and forth between sites. The goal 