version images

chef-boneyard · Aug 26, 2014 · a9afb05 · a9afb05
1 parent 8ab7008
commit a9afb05
Show file tree

Hide file tree

Showing 12 changed files with 6 additions and 6 deletions.
diff --git a/images/oec_server_deploy_be.png b/images/oec_server_deploy_be.png
diff --git a/images/oec_server_deploy_fe.png b/images/oec_server_deploy_fe.png
diff --git a/images/oec_server_deploy_febe.png b/images/oec_server_deploy_febe.png
diff --git a/images/oec_server_deploy_febe_300dpi.png b/images/oec_server_deploy_febe_300dpi.png
diff --git a/images/oec_server_deploy_standalone.png b/images/oec_server_deploy_standalone.png
diff --git a/images/oec_ha.png → images_old/oec_ha.png b/images/oec_ha.png → images_old/oec_ha.png
diff --git a/includes_server_deploy/includes_server_deploy_be.rst b/includes_server_deploy/includes_server_deploy_be.rst
@@ -3,7 +3,7 @@
 
 A scaled back end deployment is the most common starting point for high availability, with regard to |chef server oec|. It is easier to scale out and load balance the front end servers later, but it's essential to set up the back end servers for primary/secondary failover, system backups, and so on, as part of the initial configuration. Most |chef server oec| customers choose this configuration.
 
-.. image:: ../../images/oec_server_deploy_be.png
+.. image:: ../../images_old/oec_server_deploy_be.png
 
 where:
 

diff --git a/includes_server_deploy/includes_server_deploy_fe.rst b/includes_server_deploy/includes_server_deploy_fe.rst
@@ -3,7 +3,7 @@
 
 A scaled front end deployment is ideal for organizations that know they will need to plan for high availability, but also have internal requirements for back end high availability that are different from the scaled back end scenario. This is fine, of course. |chef server oec| can be configured for back end high availability in many different ways. This scenario recognizes that the back end high availability decisions are your own, but that deploying for front end high availability is also a requirement.
 
-.. image:: ../../images/oec_server_deploy_fe.png
+.. image:: ../../images_old/oec_server_deploy_fe.png
 
 where:
 

diff --git a/includes_server_deploy/includes_server_deploy_febe.rst b/includes_server_deploy/includes_server_deploy_febe.rst
@@ -3,7 +3,7 @@
 
 A scaled front and back end deployment is for those organizations that know they need high availability right from the start.
 
-.. image:: ../../images/oec_server_deploy_febe.png
+.. image:: ../../images_old/oec_server_deploy_febe.png
 
 where:
 

diff --git a/includes_server_deploy/includes_server_deploy_standalone.rst b/includes_server_deploy/includes_server_deploy_standalone.rst
@@ -5,6 +5,6 @@ A standalone deployment is a great way to test out |chef server oec|. All of the
 
 A standalone deployment can also be more than just a testing deployment. Many organizations use the standalone configuration in production environments. If your organization expects to have only a few hundred nodes and doesn't anticipate the need to scale horizontally or vertically, then this configuration may be the best option. Depending on the hardware on which |chef server oec| is installed, a standalone deployment can easily handle organization sizes well beyond several thousand nodes, so there is room for growth as long as the hardware on which the server is installed can support that growth.
 
-.. image:: ../../images/oec_server_deploy_standalone.png
+.. image:: ../../images_old/oec_server_deploy_standalone.png
 
 where no additional steps are taken for high availability. In some organizations, this approach is fine. It all depends on the capabilities of the hardware on which the services are installed and what the long-term growth expectations are for the number of nodes that will need to be managed over time. If the need to add any type of high availability arises (be it front end load balancing or back end failover), that type of change would likely come with some disruption while the switch over to new hardware and software reconfiguration takes place.
diff --git a/release_oec_11-0/source/server_high_availability.rst b/release_oec_11-0/source/server_high_availability.rst
@@ -19,7 +19,7 @@ Failover on the back-end servers is achieved using the following:
 * A primary and backup cluster election using |vrrp| over unicast TCP/IP and |keepalived|
 * A virtual IP address to the primary server, maintained based on the results of the election done by |keepalived|
 
-.. image:: ../../images/oec_ha.png
+.. image:: ../../images_old/oec_ha.png
 
 The front-end servers require load-balancers. |company_name| recommends:
 

diff --git a/release_oec_11-1/source/server_high_availability.rst b/release_oec_11-1/source/server_high_availability.rst
@@ -19,7 +19,7 @@ Failover on the back-end servers is achieved using the following:
 * A primary and backup cluster election using |vrrp| over unicast TCP/IP and |keepalived|
 * A virtual IP address to the primary server, maintained based on the results of the election done by |keepalived|
 
-.. image:: ../../images/oec_ha.png
+.. image:: ../../images_old/oec_ha.png
 
 The front-end servers require load-balancers. |company_name| recommends: