How to build a private IaaS cloud platform? - Part I, Servers
By Karoly Vegh-Oracle on Jan 03, 2013
This is Part I of the series "How to build a private IaaS cloud platform?", elaborating about the platform requirements to face when building a multipurpose Infrastructure as a Service platform.
In this post we are looking into the requirements the chosen servers have to fulfill.
See the Main Summary Post with links to the other sections (requirements analysis for OS, shared storage, virtualization, etc) here.
Part I: CPU and Server
What are the requirements a server and its CPU architecture need to fulfill to be chosen as an IaaS cloud building block?
- CPU Threading: Your customers are going to want to run a lot of different applications on the cloud platform we're building, all with different preferences for threading capabilities. Some will require strong multithreading and throughput, others will prefer high single-thread performance, and there are those that need both these (e.g. the Oracle Database). That is, the choice of CPU can't simply concentrate on one profile, will have to fulfill both, to be considered a general purpose cloud architecture.
- Data Encryption Overhead: Your customers will be concerned by the fact that within your cloud eventually other projects, other customers have their applications running too. The question about data security will rise inevitably: "Is my data secure in your cloud?". Sure it is. As long as it is encrypted, you're on the safe side. I hear you say: "But encryption is so expensive in terms of performance!". Right. Usually it is. That is, another requirement for your platform: Keep the encryption overhead as small as possible.
- Migration risks: Many of your customers are running a large number of servers, legacy applications on legacy setups on legacy platforms, and are cautious about platform upgrades for risking breaking their applications' functionality. To provide a general purpose consolidation platform, you have to minimize the migration risk.
- Virtualisation: Obviously we're going to run virtual machines on the platform, and the server/CPU of choice must support this intention. Virtualisation requirements alone need an own discussion and will be discussed in the next post.
- Consolidation power: Any server worth its salt to be considered as a consolidation platform must be powerful enough to run a plethora of virtual machines.
Alright, we got this far. We have some important requirements to fulfill. Now let me introduce you to the SPARC T4 Servers in case you were not familiar with them - and also, allow me to show you how they fulfill these requirements.
SPARC T4 CPU and Servers:
How the T4 fulfills these requirements:
- CPU Threading: The SPARC T4 CPUs all have 8 cores. Each of these 8 cores run 8 threads paralelly, sharing the resources of that CPU core. That's right, that's 64 threads per core. That is, this is one of the modes it can run in. It also capable to run one thread, dedicating it all the power of the complete CPU core. That is, the T4 CPUs provide both single-thread and throughput performance. The best thing about this? The scheduler switches between the modes on-the-fly, dynamically, that is, the switch happens in operation, transparently. We call this dynamic threading.
Conclusion: the T4 CPUs fulfill both singlethread and throughput requirements, making them an excellent general-purpose platform and a great choice for IaaS implementations.
- Data Encryption Overhead: The T4 CPUs got hardware-encryption engines within their CPUcores. These are actual encryption- and hashing algorithms cast into silicon. That's right, math in metal(loid). Solaris can use these encryption engines to encrypt data at hardware speed, without having to calculate everything in software, thus sparing CPU cycles. It won't get faster than that. Encrypt your Databases (TDE), filesystems (ZFS), SSL traffic, Java application data (JCE), etc. Data safety without encryption overhead, at your fingertips.
Conclusion: The T4 Servers with their zero-overhead encryption are the right choice for building multitenant platforms, like IaaS environments.
- Migration risk: The CPU in question is a SPARC CPU. The SPARC Instruction Set has been only extended over time, that is, if you had your application running on an earlier SPARC CPU then the operation on the newer generation SPARC CPUs is guaranteed. You can of course recompile it to benefit from the new CPUfeatures, but that isn't a requirement to run the application. Also, for the binary compatibility regarding Solaris, see the Oracle Solaris Guarantee Program.
Conclusion: The application migration between legacy SPARC servers to current T4 servers is minimized.
- Virtualisation: the SPARC T4 servers carry a unique virtualisation technology in their firmware that allows you to carve up the boxes into several virtual machines called logical domains - I will dedicate these a complete followup post.
- Consolidation power: In a 4-Socket T4 Server (the T4-4) there are 4 CPUs, each with 8 CPU cores that can run 8 threads. That is 4x8x8 == 256 threads that can be executed parallelly. How many of your average servers can you consolidate on a box like this, let's say, with 2TB RAM?
Conclusion: there is a lot of power under the engine hood of the T4 servers to offer for serverconsolidation projects.
The T4 servers fulfill the most common Infrastructure as a Service platform requirements with dynamic threading characteristics to serve all kinds of application performancerequirements, built-in virtualization for multitenancy, HW-encryption for data safety, keeping migration risk at a minimum with SPARC backward compatibility, and a lot of computing power and throughput for platform consolidation.In the next blogpost we will look into the virtualization technology for the platform, its requirements to fulfill and how it is included - OVM for SPARC, aka LDoms.