Architectural decisions around designing Server Pools

This section will not only guide us but also help us make the right architectural decisions around choosing the type of Server Pool for our Data Center. Designing a Data Center brings several challenges. Knowing how to not only architecturally design but also to orchestrate their roles within the substrate with embedded Oracle VM virtualization, helps us get closer to our goal of designing the Data Center or as we call it fondly Oracle VM farm. We will be using the term IntraCloud, which is nothing but the Private Cloud within the confines of your data center.

We obviously need to know how many servers we have and what role they will be playing within the Oracle VM environment. More capacity and more VMs will demand for more Oracle VM Servers in the Server Pool and therefore more hardware will be needed for that specific Server Pool. It is almost like adding more stateless servers to the Server Pool and thus creating an infinite array of servers in the Data Center. Simply said, these Server Pools are scalable and applications that are able to leverage the scalability will benefit the most out of such a scaled out Server Pool.

All that we need is extra or sufficient hardware capacity and we are ready to serve up more on-demand kind of workloads adaptively.

Now, let's take a look at the three kinds of Server Pools that we had mentioned previously in brief.

• Separate configuration: Here we will have servers performing a single task, one or more physical host(s) will function as Oracle VM Server, one or more physical servers can act as Utility Servers, and one single hardware box can function as Server Pool Master.
   
  This is a typical configuration when a large number of servers are required in a large Data Center. We could be looking at Data Centers with several thousands of physical servers. In this way, large capacity can be addressed and the consumption of the 4-core resources such as CPU, Network, RAM, and Storage can be evenly spread across the large substrate of stateless Oracle VM Servers.
   
  As we can see in the following diagram, the array of stateless Oracle VM Servers and the Utility Servers can be very elastic by adding or pausing capacity on-demand.

• All-in-one SMB box: This is a typical shop with few employees and a handful of servers that is looking to consolidate the current infrastructure with Oracle VM environment. It is a perfect case of building an IntraCloud environment where we can appoint one single server to conduct the following actions. It could be a Server Pool Master and a Utility Server, and also play the role of an Oracle VM Server to host the VMs.
   
  The ease of management and provisioning can be combined by smaller organizations to effectively optimize their already reduced staff members or Full Time Employees (FTEs).

• Two-in-one SMB+ configuration: This is a typical configuration where a typical SMB shop, with approximately 20-50 Servers and about 5-8 FTEs, can deploy a single physical host to function as a Server Pool Master and as a Utility Server. The rest of the Servers can be consolidated to much fewer physical hosts, say 4-5 high-end servers, that can function as highly scalable Oracle VM Servers.
  
  This scenario, as mentioned, is a typical IT shop that has moderate workloads and consumption peaks occasionally and can be handled effectively by the scalable Oracle VM Servers. However, note that the Oracle Utility and Server Pool Master Servers are not simply single servers per se. They should be duly backed up and IT shops should consider looking to migrate applications or workloads towards the Cloud infrastructures, whether in-house, internal clouds, or private clouds (external, but yet within the private domains of the outsourcing parties).