re (Butler, 2016; Amazon Web Services, 2013; Hoff, 2015; Taylor, 2016). Factoring in VF-attributable failures, VF availability at a single site would be lower. In this case, these functions would need to make use of georedundancy across multiple sites to achieve high availability. 5.2 THE IMPACT OF PLANNED DOWNTIME AND GEOREDUNDANCY The previous section considered VF availability assuming no planned downtime. This represents the pre-NFV state, where physical network elements were designed for "hitless upgrades" or with tightly constrained upgrade procedures. By contrast, Network Cloud environments may be designed with lengthy planned downtimes to perform infrastructure upgrades, often driven by the reality that much of the open-source software employed in cloud environments (host operating system [OS], compute and I/O virtualization, OpenStack orchestration, etc.) is still in its infancy and lacks the maturity that comes with years of rigorous testing to ensure code stability and backward compatibility. 5.2.1 ILLUSTRATIVE EXAMPLE OF THE IMPACTS OF PLANNED DOWNTIME As an illustrative example of designing for planned downtime through georedundancy, Figures 5.5 and 5.6 capture the effect of planned downtime on VF availability. There are three curves in each figure representing the cumulative planned annual downtime of 0 (hitless), 1, or 2 weeks per site. The example assumes that planned maintenance takes down the entire site. The x-axis shows the single-site cloud availability, and the y-axis shows the maximum VF availability (excluding VF application downtime). Figure 5.5 assumes that the VF is replicated across two sites, with 100% of the total required VF capacity provisioned at each site (200% total). Thus, at least one of the Architecting the Network Cloud for High Availability 100.000% 99.999% 99.998% 99.997% 99.996% 99.995% 99.994% 99.993% 200% capacity 1 of 2 sites must 99.992% be available 99.991% 2 weeks per year per site Network Cloud Site Availability 99.990% 99.00% 99.50% 99.90% 99.95% 99.99% FIGURE 5.5