diff --git a/doc/arch-design/ch_compute_focus.xml b/doc/arch-design/ch_compute_focus.xml index 8661723afa..85b085d889 100644 --- a/doc/arch-design/ch_compute_focus.xml +++ b/doc/arch-design/ch_compute_focus.xml @@ -6,7 +6,42 @@ xml:id="compute_focus"> Compute focused - + A compute-focused cloud is a specialized subset of the general purpose + OpenStack cloud architecture. Unlike the general purpose OpenStack + architecture, which is built to host a wide variety of workloads and + applications and does not heavily tax any particular computing aspect, + a compute-focused cloud is built and designed specifically to support + compute intensive workloads. As such, the design must be specifically + tailored to support hosting compute intensive workloads. Compute intensive + workloads may be CPU intensive, RAM intensive, or both. However, they are + not typically storage intensive or network intensive. Compute-focused + workloads may include the following use cases: + + + High performance computing (HPC) + + + Big data analytics using Hadoop or other distributed data + stores + + + Continuous integration/continuous deployment (CI/CD) + + + Platform-as-a-Service (PaaS) + + + Signal processing for Network Function Virtualization (NFV) + + + Based on the use case requirements, such clouds might need to provide + additional services such as a virtual machine disk library, file or object + storage, firewalls, load balancers, IP addresses, and network connectivity + in the form of overlays or virtual Local Area Networks (VLANs). A + compute-focused OpenStack cloud will not typically use raw block storage + services since the applications hosted on a compute-focused OpenStack + cloud generally do not need persistent block storage. + diff --git a/doc/arch-design/ch_generalpurpose.xml b/doc/arch-design/ch_generalpurpose.xml index 929933c5aa..3ffd6341c3 100644 --- a/doc/arch-design/ch_generalpurpose.xml +++ b/doc/arch-design/ch_generalpurpose.xml @@ -6,7 +6,63 @@ xml:id="generalpurpose"> General purpose - + An OpenStack general purpose cloud is often considered a + starting point for building a cloud deployment. General + purpose clouds, by their nature, balance the components and do + not emphasize (or heavily emphasize) any particular aspect of + the overall computing environment. The expectation is that the + compute, network, and storage components will be given equal + weight in the design. General purpose clouds can be found in + private, public, and hybrid environments. They lend themselves + to many different use cases but, since they are homogeneous + deployments, they are not suited to specialized environments + or edge case situations. Common uses to consider for a general + purpose cloud could be, but are not limited to, providing a + simple database, a web application runtime environment, a + shared application development platform, or lab test bed. In + other words, any use case that would benefit from a scale-out + rather than a scale-up approach is a good candidate for a + general purpose cloud architecture. + A general purpose cloud, by definition, is something that is + designed to have a range of potential uses or functions; not + specialized for a specific use. General purpose architecture + is largely considered a scenario that would address 80% of the + potential use cases. The infrastructure, in itself, is a + specific use case. It is also a good place to start the design + process. As the most basic cloud service model, general + purpose clouds are designed to be platforms suited for general + purpose applications. + General purpose clouds are limited to the most basic + components, but they can include additional resources such + as: + + + Virtual-machine disk image library + + + Raw block storage + + + File or object storage + + + Firewalls + + + Load balancers + + + IP addresses + + + Network overlays or virtual local area networks + (VLANs) + + + Software bundles + + + diff --git a/doc/arch-design/ch_hybrid.xml b/doc/arch-design/ch_hybrid.xml index d2fd4912d1..f7a03131ff 100644 --- a/doc/arch-design/ch_hybrid.xml +++ b/doc/arch-design/ch_hybrid.xml @@ -6,7 +6,67 @@ xml:id="hybrid"> Hybrid - + Hybrid cloud, by definition, means that the design spans + more than one cloud. An example of this kind of architecture + may include a situation in which the design involves more than + one OpenStack cloud (for example, an OpenStack-based private + cloud and an OpenStack-based public cloud), or it may be a + situation incorporating an OpenStack cloud and a non-OpenStack + cloud (for example, an OpenStack-based private cloud that + interacts with Amazon Web Services). Bursting into an external + cloud is the practice of creating new instances to alleviate + extra load where there is no available capacity in the private + cloud. + Some situations that could involve hybrid cloud architecture + include: + + + Bursting from a private cloud to a public + cloud + + + Disaster recovery + + + Development and testing + + + Federated cloud, enabling users to choose resources + from multiple providers + + + Hybrid clouds built to support legacy systems as + they transition to cloud + + + As a hybrid cloud design deals with systems that are outside + of the control of the cloud architect or organization, a + hybrid cloud architecture requires considering aspects of the + architecture that might not have otherwise been necessary. For + example, the design may need to deal with hardware, software, + and APIs under the control of a separate organization. + Similarly, the degree to which the architecture is + OpenStack-based will have an effect on the cloud operator or + cloud consumer's ability to accomplish tasks with native + OpenStack tools. By definition, this is a situation in which + no single cloud can provide all of the necessary + functionality. In order to manage the entire system, users, + operators and consumers will need an overarching tool known as + a cloud management platform (CMP). Any organization that is + working with multiple clouds already has a CMP, even if that + CMP is the operator who logs into an external web portal and + launches a public cloud instance. + There are commercially available options, such as + Rightscale, and open source options, such as ManageIQ + (http://manageiq.org/), but there is no single CMP that can + address all needs in all scenarios. Whereas most of the + sections of this book talk about the aspects of OpenStack, an + architect needs to consider when designing an OpenStack + architecture. This section will also discuss the things the + architect must address when choosing or building a CMP to run + a hybrid cloud design, even if the CMP will be a manually + built solution. + @@ -14,4 +74,3 @@ - diff --git a/doc/arch-design/ch_introduction.xml b/doc/arch-design/ch_introduction.xml index 93117576cf..45f76a93a9 100644 --- a/doc/arch-design/ch_introduction.xml +++ b/doc/arch-design/ch_introduction.xml @@ -6,7 +6,31 @@ xml:id="introduction"> Introduction - + OpenStack is a leader in the cloud technology gold rush, as + organizations of all stripes discover the increased + flexibility and speed to market that self-service cloud and + Infrastructure-as-a-Service (IaaS) provides. To truly reap + those benefits, however, the cloud must be designed and + architected properly. + A well-architected cloud provides a stable IT environment + that offers easy access to needed resources, usage-based + expenses, extra capacity on demand, disaster recovery, and a + secure environment, but a well-architected cloud does not + magically build itself. It requires careful consideration of a + multitude of factors, both technical and non-technical. + There is no single architecture that is "right" for an + OpenStack cloud deployment. OpenStack can be used for any + number of different purposes, and each of them has its own + particular requirements and architectural + peculiarities. + This book is designed to look at some of the most common + uses for OpenStack clouds (and even some that are less common, + but provide a good example) and explain what issues need to be + considered and why, along with a wealth of knowledge and + advice to help an organization to design and build a + well-architected OpenStack cloud that will fit its unique + requirements. + diff --git a/doc/arch-design/ch_massively_scalable.xml b/doc/arch-design/ch_massively_scalable.xml index ec45ba54cd..7d51996ccd 100644 --- a/doc/arch-design/ch_massively_scalable.xml +++ b/doc/arch-design/ch_massively_scalable.xml @@ -6,7 +6,74 @@ xml:id="massively_scalable"> Massively scalable - + A massively scalable architecture is defined as a cloud + implementation that is either a very large deployment, such as + one that would be built by a commercial service provider, or + one that has the capability to support user requests for large + amounts of cloud resources. An example would be an + infrastructure in which requests to service 500 instances or + more at a time is not uncommon. In a massively scalable + infrastructure, such a request is fulfilled without completely + consuming all of the available cloud infrastructure resources. + While the high capital cost of implementing such a cloud + architecture makes it cost prohibitive and is only spearheaded + by few organizations, many organizations are planning for + massive scalability moving toward the future. + A massively scalable OpenStack cloud design presents a + unique set of challenges and considerations. For the most part + it is similar to a general purpose cloud architecture, as it + is built to address a non-specific range of potential use + cases or functions. Typically, it is rare that massively + scalable clouds are designed or specialized for particular + workloads. Like the general purpose cloud, the massively + scalable cloud is most often built as a platform for a variety + of workloads. Massively scalable OpenStack clouds are + generally built as commercial public cloud offerings since + single private organizations rarely have the resources or need + for this scale. + Services provided by a massively scalable OpenStack cloud + will include: + + + Virtual-machine disk image library + + + Raw block storage + + + File or object storage + + + Firewall functionality + + + Load balancing functionality + + + Private (non-routable) and public (floating) IP + addresses + + + Virtualized network topologies + + + Software bundles + + + Virtual compute resources + + + Like a general purpose cloud, the instances deployed in a + massively scalable OpenStack cloud will not necessarily use + any specific aspect of the cloud offering (compute, network, + or storage). As the cloud grows in scale, the scale of the + number of workloads can cause stress on all of the cloud + components. Additional stresses are introduced to supporting + infrastructure including databases and message brokers. The + architecture design for such a cloud must account for these + performance pressures without negatively impacting user + experience. + diff --git a/doc/arch-design/ch_multi_site.xml b/doc/arch-design/ch_multi_site.xml index 62aced395b..8e0ec2e622 100644 --- a/doc/arch-design/ch_multi_site.xml +++ b/doc/arch-design/ch_multi_site.xml @@ -6,7 +6,32 @@ xml:id="multi_site"> Multi-site - + A multi-site OpenStack environment is one in which services + located in more than one data center are used to provide the + overall solution. Usage requirements of different multi-site + clouds may vary widely, however they share some common needs. + OpenStack is capable of running in a multi-region + configuration allowing some parts of OpenStack to effectively + manage a grouping of sites as a single cloud. With some + careful planning in the design phase, OpenStack can act as an + excellent multi-site cloud solution for a multitude of + needs. + Some use cases that might indicate a need for a multi-site + deployment of OpenStack include: + + + An organization with a diverse geographic + footprint. + + + Geo-location sensitive data. + + + Data locality, in which specific data or + functionality should be close to users. + + + diff --git a/doc/arch-design/ch_network_focus.xml b/doc/arch-design/ch_network_focus.xml index 8bcc37c154..3343ea4716 100644 --- a/doc/arch-design/ch_network_focus.xml +++ b/doc/arch-design/ch_network_focus.xml @@ -6,7 +6,137 @@ xml:id="network_focus"> Network focused - + All OpenStack deployments are dependent, to some extent, on + network communication in order to function properly due to a + service-based nature. In some cases, however, use cases + dictate that the network is elevated beyond simple + infrastructure. This section is a discussion of architectures + that are more reliant or focused on network services. These + architectures are heavily dependent on the network + infrastructure and need to be architected so that the network + services perform and are reliable in order to satisfy user and + application requirements. + Some possible use cases include: + + + Content Delivery Network: This could include + streaming video, photographs or any other cloud based + repository of data that is distributed to a large + number of end users. Mass market streaming video will + be very heavily affected by the network configurations + that would affect latency, bandwidth, and the + distribution of instances. Not all video streaming is + consumer focused. For example, multicast videos (used + for media, press conferences, corporate presentations, + web conferencing services, and so on) can also utilize a + content delivery network. Content delivery will be + affected by the location of the video repository and + its relationship to end users. Performance is also + affected by network throughput of the backend systems, + as well as the WAN architecture and the cache + methodology. + + + Network Management Functions: A cloud that provides + network service functions would be built to support + the delivery of back-end network services such as DNS, + NTP or SNMP and would be used by a company for + internal network management. + + + Network Service Offerings: A cloud can be used to + run customer facing network tools to support services. + For example, VPNs, MPLS private networks, GRE tunnels + and others. + + + Web portals / Web Services: Web servers are a common + application for cloud services and it is recommended + to have an understanding of the network requirements. + The network will need to be able to scale out to meet + user demand and deliver webpages with a minimum of + latency. Internal east-west and north-south network + bandwidth must be considered depending on the details + of the portal architecture. + + + High Speed and High Volume Transactional Systems: + These types of applications are very sensitive to + network configurations. Examples include many + financial systems, credit card transaction + applications, trading and other extremely high volume + systems. These systems are sensitive to network jitter + and latency. They also have a high volume of both + east-west and north-south network traffic that needs + to be balanced to maximize efficiency of the data + delivery. Many of these systems have large high + performance database back ends that need to be + accessed. + + + High Availability: These types of use cases are + highly dependent on the proper sizing of the network + to maintain replication of data between sites for high + availability. If one site becomes unavailable, the + extra sites will be able to serve the displaced load + until the original site returns to service. It is + important to size network capacity to handle the loads + that are desired. + + + Big Data: Clouds that will be used for the + management and collection of big data (data ingest) + will have a significant demand on network resources. + Big data often uses partial replicas of the data to + maintain data integrity over large distributed clouds. + Other big data applications that require a large + amount of network resources are Hadoop, Cassandra, + NuoDB, RIAK and other No-SQL and distributed + databases. + + + Virtual Desktop Infrastructure (VDI): This use case + is very sensitive to network congestion, latency, + jitter and other network characteristics. Like video + streaming, the user experience is very important + however, unlike video streaming, caching is not an + option to offset the network issues. VDI requires both + upstream and downstream traffic and cannot rely on + caching for the delivery of the application to the end + user. + + + Voice over IP (VoIP): This is extremely sensitive to + network congestion, latency, jitter and other network + characteristics. VoIP has a symmetrical traffic + pattern and it requires network quality of service + (QoS) for best performance. It may also require an + active queue management implementation to ensure + delivery. Users are very sensitive to latency and + jitter fluctuations and can detect them at very low + levels. + + + Video Conference / Web Conference: This also is + extremely sensitive to network congestion, latency, + jitter and other network flaws. Video Conferencing has + a symmetrical traffic pattern, but unless the network + is on an MPLS private network, it cannot use network + quality of service (QoS) to improve performance. + Similar to VOIP, users will be sensitive to network + performance issues even at low levels. + + + High Performance Computing (HPC): This is a complex + use case that requires careful consideration of the + traffic flows and usage patterns to address the needs + of cloud clusters. It has high East-West traffic + patterns for distributed computing, but there can be + substantial North-South traffic depending on the + specific application. + + + diff --git a/doc/arch-design/ch_specialized.xml b/doc/arch-design/ch_specialized.xml index d8cb3c7645..ce99a80332 100644 --- a/doc/arch-design/ch_specialized.xml +++ b/doc/arch-design/ch_specialized.xml @@ -6,7 +6,48 @@ xml:id="specialized"> Specialized cases - + Although most OpenStack architecture designs fall into one + of the seven major scenarios outlined in other sections + (compute focused, network focused, storage focused, general + purpose, multi-site, hybrid cloud, and massively scalable), + there are a few other use cases that are unique enough they + can't be neatly categorized into one of the other major + sections. This section discusses some of these unique use + cases with some additional details and design considerations + for each use case: + + + Specialized Networking: This describes running + networking-oriented software that may involve reading + packets directly from the wire or participating in + routing protocols. + + + Software-Defined Networking: This use case details + both running an SDN controller from within OpenStack + as well as participating in a software-defined + network. + + + Desktop-as-a-Service: This is for organizations that + want to run a virtualized desktop environment on a + cloud. This can apply to private or public + clouds. + + + OpenStack on OpenStack: Some organizations are + finding that it makes technical sense to build a + multi-tiered cloud by running OpenStack on top of an + OpenStack installation. + + + Specialized Hardware: Some highly specialized + situations will require the use of specialized + hardware devices from within the OpenStack + environment. + + + diff --git a/doc/arch-design/ch_storage_focus.xml b/doc/arch-design/ch_storage_focus.xml index d9ac783e92..eb1808ccfa 100644 --- a/doc/arch-design/ch_storage_focus.xml +++ b/doc/arch-design/ch_storage_focus.xml @@ -6,7 +6,70 @@ xml:id="storage_focus"> Storage focused - + Cloud storage is a model of data storage where digital data + is stored in logical pools and physical storage that spans + across multiple servers and locations. Cloud storage commonly + refers to a hosted object storage service, however the term + has extended to include other types of data storage that are + available as a service, for example block storage. + Cloud storage is based on virtualized infrastructure and + resembles broader cloud computing in terms of accessible + interfaces, elasticity, scalability, multi-tenancy, and + metered resources. Cloud storage services can be utilized from + an off-premises service or deployed on-premises. + Cloud storage is made up of many distributed, yet still + synonymous resources, and is often referred to as integrated + storage clouds. Cloud storage is highly fault tolerant through + redundancy and the distribution of data. It is highly durable + through the creation of versioned copies, and can be + consistent with regard to data replicas. + At a certain scale, management of data operations can become + a resource intensive process to an organization. Hierarchical + storage management (HSM) systems and data grids can help + annotate and report a baseline data valuation to make + intelligent decisions and automate data decisions. HSM allows + for automating tiering and movement, as well as orchestration + of data operations. A data grid is an architecture, or set of + services evolving technology, that brings together sets of + services allowing users to manage large data sets. + Examples of applications that can be deployed with cloud + storage characteristics are: + + + Active archive, backups and hierarchical storage + management. + + + General content storage and synchronization. An + example of this is private dropbox. + + + Data analytics with parallel file systems. + + + Unstructured data store for services. For example, + social media back-end storage. + + + Persistent block storage. + + + Operating system and application image store. + + + Media streaming. + + + Databases. + + + Content distribution. + + + Cloud storage peering. + + + diff --git a/doc/arch-design/compute_focus/section_introduction_compute_focus.xml b/doc/arch-design/compute_focus/section_introduction_compute_focus.xml deleted file mode 100644 index 9a4f8392ae..0000000000 --- a/doc/arch-design/compute_focus/section_introduction_compute_focus.xml +++ /dev/null @@ -1,43 +0,0 @@ - -
- Introduction - A compute-focused cloud is a specialized subset of the general purpose - OpenStack cloud architecture. Unlike the general purpose OpenStack - architecture, which is built to host a wide variety of workloads and - applications and does not heavily tax any particular computing aspect, - a compute-focused cloud is built and designed specifically to support - compute intensive workloads. As such, the design must be specifically - tailored to support hosting compute intensive workloads. Compute intensive - workloads may be CPU intensive, RAM intensive, or both. However, they are - not typically storage intensive or network intensive. Compute-focused - workloads may include the following use cases: - - - High performance computing (HPC) - - - Big data analytics using Hadoop or other distributed data - stores - - - Continuous integration/continuous deployment (CI/CD) - - - Platform-as-a-Service (PaaS) - - - Signal processing for Network Function Virtualization (NFV) - - - Based on the use case requirements, such clouds might need to provide - additional services such as a virtual machine disk library, file or object - storage, firewalls, load balancers, IP addresses, and network connectivity - in the form of overlays or virtual Local Area Networks (VLANs). A - compute-focused OpenStack cloud will not typically use raw block storage - services since the applications hosted on a compute-focused OpenStack - cloud generally do not need persistent block storage. -
diff --git a/doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml b/doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml deleted file mode 100644 index f7c6887f83..0000000000 --- a/doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml +++ /dev/null @@ -1,64 +0,0 @@ - -
- Introduction - An OpenStack general purpose cloud is often considered a - starting point for building a cloud deployment. General - purpose clouds, by their nature, balance the components and do - not emphasize (or heavily emphasize) any particular aspect of - the overall computing environment. The expectation is that the - compute, network, and storage components will be given equal - weight in the design. General purpose clouds can be found in - private, public, and hybrid environments. They lend themselves - to many different use cases but, since they are homogeneous - deployments, they are not suited to specialized environments - or edge case situations. Common uses to consider for a general - purpose cloud could be, but are not limited to, providing a - simple database, a web application runtime environment, a - shared application development platform, or lab test bed. In - other words, any use case that would benefit from a scale-out - rather than a scale-up approach is a good candidate for a - general purpose cloud architecture. - A general purpose cloud, by definition, is something that is - designed to have a range of potential uses or functions; not - specialized for a specific use. General purpose architecture - is largely considered a scenario that would address 80% of the - potential use cases. The infrastructure, in itself, is a - specific use case. It is also a good place to start the design - process. As the most basic cloud service model, general - purpose clouds are designed to be platforms suited for general - purpose applications. - General purpose clouds are limited to the most basic - components, but they can include additional resources such - as: - - - Virtual-machine disk image library - - - Raw block storage - - - File or object storage - - - Firewalls - - - Load balancers - - - IP addresses - - - Network overlays or virtual local area networks - (VLANs) - - - Software bundles - - -
diff --git a/doc/arch-design/hybrid/section_introduction_hybrid.xml b/doc/arch-design/hybrid/section_introduction_hybrid.xml deleted file mode 100644 index 65791e84cf..0000000000 --- a/doc/arch-design/hybrid/section_introduction_hybrid.xml +++ /dev/null @@ -1,68 +0,0 @@ - -
- Introduction - Hybrid cloud, by definition, means that the design spans - more than one cloud. An example of this kind of architecture - may include a situation in which the design involves more than - one OpenStack cloud (for example, an OpenStack-based private - cloud and an OpenStack-based public cloud), or it may be a - situation incorporating an OpenStack cloud and a non-OpenStack - cloud (for example, an OpenStack-based private cloud that - interacts with Amazon Web Services). Bursting into an external - cloud is the practice of creating new instances to alleviate - extra load where there is no available capacity in the private - cloud. - Some situations that could involve hybrid cloud architecture - include: - - - Bursting from a private cloud to a public - cloud - - - Disaster recovery - - - Development and testing - - - Federated cloud, enabling users to choose resources - from multiple providers - - - Hybrid clouds built to support legacy systems as - they transition to cloud - - - As a hybrid cloud design deals with systems that are outside - of the control of the cloud architect or organization, a - hybrid cloud architecture requires considering aspects of the - architecture that might not have otherwise been necessary. For - example, the design may need to deal with hardware, software, - and APIs under the control of a separate organization. - Similarly, the degree to which the architecture is - OpenStack-based will have an effect on the cloud operator or - cloud consumer's ability to accomplish tasks with native - OpenStack tools. By definition, this is a situation in which - no single cloud can provide all of the necessary - functionality. In order to manage the entire system, users, - operators and consumers will need an overarching tool known as - a cloud management platform (CMP). Any organization that is - working with multiple clouds already has a CMP, even if that - CMP is the operator who logs into an external web portal and - launches a public cloud instance. - There are commercially available options, such as - Rightscale, and open source options, such as ManageIQ - (http://manageiq.org/), but there is no single CMP that can - address all needs in all scenarios. Whereas most of the - sections of this book talk about the aspects of OpenStack, an - architect needs to consider when designing an OpenStack - architecture. This section will also discuss the things the - architect must address when choosing or building a CMP to run - a hybrid cloud design, even if the CMP will be a manually - built solution. -
diff --git a/doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.xml b/doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.xml deleted file mode 100644 index f050647ad2..0000000000 --- a/doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.xml +++ /dev/null @@ -1,33 +0,0 @@ - -
- Introduction to the OpenStack Architecture Design - Guide - OpenStack is a leader in the cloud technology gold rush, as - organizations of all stripes discover the increased - flexibility and speed to market that self-service cloud and - Infrastructure-as-a-Service (IaaS) provides. To truly reap - those benefits, however, the cloud must be designed and - architected properly. - A well-architected cloud provides a stable IT environment - that offers easy access to needed resources, usage-based - expenses, extra capacity on demand, disaster recovery, and a - secure environment, but a well-architected cloud does not - magically build itself. It requires careful consideration of a - multitude of factors, both technical and non-technical. - There is no single architecture that is "right" for an - OpenStack cloud deployment. OpenStack can be used for any - number of different purposes, and each of them has its own - particular requirements and architectural - peculiarities. - This book is designed to look at some of the most common - uses for OpenStack clouds (and even some that are less common, - but provide a good example) and explain what issues need to be - considered and why, along with a wealth of knowledge and - advice to help an organization to design and build a - well-architected OpenStack cloud that will fit its unique - requirements. -
diff --git a/doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml b/doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml deleted file mode 100644 index 860674f911..0000000000 --- a/doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml +++ /dev/null @@ -1,75 +0,0 @@ - -
- Introduction - A massively scalable architecture is defined as a cloud - implementation that is either a very large deployment, such as - one that would be built by a commercial service provider, or - one that has the capability to support user requests for large - amounts of cloud resources. An example would be an - infrastructure in which requests to service 500 instances or - more at a time is not uncommon. In a massively scalable - infrastructure, such a request is fulfilled without completely - consuming all of the available cloud infrastructure resources. - While the high capital cost of implementing such a cloud - architecture makes it cost prohibitive and is only spearheaded - by few organizations, many organizations are planning for - massive scalability moving toward the future. - A massively scalable OpenStack cloud design presents a - unique set of challenges and considerations. For the most part - it is similar to a general purpose cloud architecture, as it - is built to address a non-specific range of potential use - cases or functions. Typically, it is rare that massively - scalable clouds are designed or specialized for particular - workloads. Like the general purpose cloud, the massively - scalable cloud is most often built as a platform for a variety - of workloads. Massively scalable OpenStack clouds are - generally built as commercial public cloud offerings since - single private organizations rarely have the resources or need - for this scale. - Services provided by a massively scalable OpenStack cloud - will include: - - - Virtual-machine disk image library - - - Raw block storage - - - File or object storage - - - Firewall functionality - - - Load balancing functionality - - - Private (non-routable) and public (floating) IP - addresses - - - Virtualized network topologies - - - Software bundles - - - Virtual compute resources - - - Like a general purpose cloud, the instances deployed in a - massively scalable OpenStack cloud will not necessarily use - any specific aspect of the cloud offering (compute, network, - or storage). As the cloud grows in scale, the scale of the - number of workloads can cause stress on all of the cloud - components. Additional stresses are introduced to supporting - infrastructure including databases and message brokers. The - architecture design for such a cloud must account for these - performance pressures without negatively impacting user - experience. -
diff --git a/doc/arch-design/multi_site/section_introduction_multi_site.xml b/doc/arch-design/multi_site/section_introduction_multi_site.xml deleted file mode 100644 index 201dbcdd01..0000000000 --- a/doc/arch-design/multi_site/section_introduction_multi_site.xml +++ /dev/null @@ -1,33 +0,0 @@ - -
- Introduction - A multi-site OpenStack environment is one in which services - located in more than one data center are used to provide the - overall solution. Usage requirements of different multi-site - clouds may vary widely, however they share some common needs. - OpenStack is capable of running in a multi-region - configuration allowing some parts of OpenStack to effectively - manage a grouping of sites as a single cloud. With some - careful planning in the design phase, OpenStack can act as an - excellent multi-site cloud solution for a multitude of - needs. - Some use cases that might indicate a need for a multi-site - deployment of OpenStack include: - - - An organization with a diverse geographic - footprint. - - - Geo-location sensitive data. - - - Data locality, in which specific data or - functionality should be close to users. - - -
diff --git a/doc/arch-design/network_focus/section_introduction_network_focus.xml b/doc/arch-design/network_focus/section_introduction_network_focus.xml deleted file mode 100644 index ffaee56ed9..0000000000 --- a/doc/arch-design/network_focus/section_introduction_network_focus.xml +++ /dev/null @@ -1,138 +0,0 @@ - -
- Introduction - All OpenStack deployments are dependent, to some extent, on - network communication in order to function properly due to a - service-based nature. In some cases, however, use cases - dictate that the network is elevated beyond simple - infrastructure. This section is a discussion of architectures - that are more reliant or focused on network services. These - architectures are heavily dependent on the network - infrastructure and need to be architected so that the network - services perform and are reliable in order to satisfy user and - application requirements. - Some possible use cases include: - - - Content Delivery Network: This could include - streaming video, photographs or any other cloud based - repository of data that is distributed to a large - number of end users. Mass market streaming video will - be very heavily affected by the network configurations - that would affect latency, bandwidth, and the - distribution of instances. Not all video streaming is - consumer focused. For example, multicast videos (used - for media, press conferences, corporate presentations, - web conferencing services, and so on) can also utilize a - content delivery network. Content delivery will be - affected by the location of the video repository and - its relationship to end users. Performance is also - affected by network throughput of the backend systems, - as well as the WAN architecture and the cache - methodology. - - - Network Management Functions: A cloud that provides - network service functions would be built to support - the delivery of back-end network services such as DNS, - NTP or SNMP and would be used by a company for - internal network management. - - - Network Service Offerings: A cloud can be used to - run customer facing network tools to support services. - For example, VPNs, MPLS private networks, GRE tunnels - and others. - - - Web portals / Web Services: Web servers are a common - application for cloud services and it is recommended - to have an understanding of the network requirements. - The network will need to be able to scale out to meet - user demand and deliver webpages with a minimum of - latency. Internal east-west and north-south network - bandwidth must be considered depending on the details - of the portal architecture. - - - High Speed and High Volume Transactional Systems: - These types of applications are very sensitive to - network configurations. Examples include many - financial systems, credit card transaction - applications, trading and other extremely high volume - systems. These systems are sensitive to network jitter - and latency. They also have a high volume of both - east-west and north-south network traffic that needs - to be balanced to maximize efficiency of the data - delivery. Many of these systems have large high - performance database back ends that need to be - accessed. - - - High Availability: These types of use cases are - highly dependent on the proper sizing of the network - to maintain replication of data between sites for high - availability. If one site becomes unavailable, the - extra sites will be able to serve the displaced load - until the original site returns to service. It is - important to size network capacity to handle the loads - that are desired. - - - Big Data: Clouds that will be used for the - management and collection of big data (data ingest) - will have a significant demand on network resources. - Big data often uses partial replicas of the data to - maintain data integrity over large distributed clouds. - Other big data applications that require a large - amount of network resources are Hadoop, Cassandra, - NuoDB, RIAK and other No-SQL and distributed - databases. - - - Virtual Desktop Infrastructure (VDI): This use case - is very sensitive to network congestion, latency, - jitter and other network characteristics. Like video - streaming, the user experience is very important - however, unlike video streaming, caching is not an - option to offset the network issues. VDI requires both - upstream and downstream traffic and cannot rely on - caching for the delivery of the application to the end - user. - - - Voice over IP (VoIP): This is extremely sensitive to - network congestion, latency, jitter and other network - characteristics. VoIP has a symmetrical traffic - pattern and it requires network quality of service - (QoS) for best performance. It may also require an - active queue management implementation to ensure - delivery. Users are very sensitive to latency and - jitter fluctuations and can detect them at very low - levels. - - - Video Conference / Web Conference: This also is - extremely sensitive to network congestion, latency, - jitter and other network flaws. Video Conferencing has - a symmetrical traffic pattern, but unless the network - is on an MPLS private network, it cannot use network - quality of service (QoS) to improve performance. - Similar to VOIP, users will be sensitive to network - performance issues even at low levels. - - - High Performance Computing (HPC): This is a complex - use case that requires careful consideration of the - traffic flows and usage patterns to address the needs - of cloud clusters. It has high East-West traffic - patterns for distributed computing, but there can be - substantial North-South traffic depending on the - specific application. - - -
diff --git a/doc/arch-design/specialized/section_introduction_specialized.xml b/doc/arch-design/specialized/section_introduction_specialized.xml deleted file mode 100644 index e1929644a0..0000000000 --- a/doc/arch-design/specialized/section_introduction_specialized.xml +++ /dev/null @@ -1,49 +0,0 @@ - -
- Introduction - Although most OpenStack architecture designs fall into one - of the seven major scenarios outlined in other sections - (compute focused, network focused, storage focused, general - purpose, multi-site, hybrid cloud, and massively scalable), - there are a few other use cases that are unique enough they - can't be neatly categorized into one of the other major - sections. This section discusses some of these unique use - cases with some additional details and design considerations - for each use case: - - - Specialized Networking: This describes running - networking-oriented software that may involve reading - packets directly from the wire or participating in - routing protocols. - - - Software-Defined Networking: This use case details - both running an SDN controller from within OpenStack - as well as participating in a software-defined - network. - - - Desktop-as-a-Service: This is for organizations that - want to run a virtualized desktop environment on a - cloud. This can apply to private or public - clouds. - - - OpenStack on OpenStack: Some organizations are - finding that it makes technical sense to build a - multi-tiered cloud by running OpenStack on top of an - OpenStack installation. - - - Specialized Hardware: Some highly specialized - situations will require the use of specialized - hardware devices from within the OpenStack - environment. - - -
diff --git a/doc/arch-design/storage_focus/section_introduction_storage_focus.xml b/doc/arch-design/storage_focus/section_introduction_storage_focus.xml deleted file mode 100644 index c51f49c186..0000000000 --- a/doc/arch-design/storage_focus/section_introduction_storage_focus.xml +++ /dev/null @@ -1,71 +0,0 @@ - -
- Introduction - Cloud storage is a model of data storage where digital data - is stored in logical pools and physical storage that spans - across multiple servers and locations. Cloud storage commonly - refers to a hosted object storage service, however the term - has extended to include other types of data storage that are - available as a service, for example block storage. - Cloud storage is based on virtualized infrastructure and - resembles broader cloud computing in terms of accessible - interfaces, elasticity, scalability, multi-tenancy, and - metered resources. Cloud storage services can be utilized from - an off-premises service or deployed on-premises. - Cloud storage is made up of many distributed, yet still - synonymous resources, and is often referred to as integrated - storage clouds. Cloud storage is highly fault tolerant through - redundancy and the distribution of data. It is highly durable - through the creation of versioned copies, and can be - consistent with regard to data replicas. - At a certain scale, management of data operations can become - a resource intensive process to an organization. Hierarchical - storage management (HSM) systems and data grids can help - annotate and report a baseline data valuation to make - intelligent decisions and automate data decisions. HSM allows - for automating tiering and movement, as well as orchestration - of data operations. A data grid is an architecture, or set of - services evolving technology, that brings together sets of - services allowing users to manage large data sets. - Examples of applications that can be deployed with cloud - storage characteristics are: - - - Active archive, backups and hierarchical storage - management. - - - General content storage and synchronization. An - example of this is private dropbox. - - - Data analytics with parallel file systems. - - - Unstructured data store for services. For example, - social media back-end storage. - - - Persistent block storage. - - - Operating system and application image store. - - - Media streaming. - - - Databases. - - - Content distribution. - - - Cloud storage peering. - - -