After some coffee and quick introduction of the students, we jumped into the course material, which consisted of the following topics:
1. Course introduction and the modules overview.
2. Design Process Overview: this module describes the design methodology, criteria and approach. The module describes the following phases in the design methodology: Architectural vision (scope, goals, requirements, assumptions, constrains, risks), Architectural analysis (a current-state analysis of the existing infrastructure), Technology architecture (create a conceptual, logical and physical design). The design criteria should include the usability (performance, availability, and scalability), manageability (easy to deploy, administer, maintain and update/upgrade), security (minimize risks) and costs (meet the needs and objectives, fit within the budget). At the end of this module, there is an example of the design process. This example will show and guide you through the design process and as a final step; it will describe what documents will be created (required and optional).
3. Host design module: this module concentrates on making the host design decisions based on the gathered information. This concerns the following:
- CPU capacity and number of hosts: one of many methods to gather the CPU usage is the VMware Capacity Planner. You could also use the OS build-in CPU monitoring utility like Perfmon in Windows operating systems. Do not saturate the CPU with workloads. Leave some spare room for future growth, ESX Service Console, VMkernel, VMware HA etc.
- Number of CPU cores per host: beside the preference of a certain model keep in mind that the number of the physical CPU cores should exceed the number of the vCPU’s in the largest Virtual Machine. More on this topic can be found in the “VMware vSphere CPU Scheduler in VMware ESX” document.
- Number of vCPU per core: the number of vCPU’s per processor core is mostly determined by the VMware support maximum. Check the “Configurations Maximums for VMware vSphere” document for detailed information because the supported maximums can change with a new software release.
- CPU features: first of all the processor must be x64-bits. The x32-bits systems are no longer applicable. Check if the chosen processor supports the VT-x and EPT from Intel and the AMD-V and RVI from AMD.
- Licensing: the licensing for CPU’s concerns two major aspects. The chosen license must support the total number of CPU sockets and the total number of the cores per socket.
- Memory capacity and number of hosts: just like in the CPU capacity sub-topic described above, you could use the VMware Capacity Planner or an OS build-in utility to measure the memory resource usage on the systems. This should give you an overview of the amount of the current memory capacity and from there you can calculate the needed memory capacity for the new environment. Keep some spare room for future growth, VM’s and Service Console overhead, VMware HA etc.
- Memory overcommitment: overcommitting the total physical memory of a host could save costs but keep in mind that if the active memory is overcommitted the VM’s will be forced to use the memory saving techniques to compensate the physical memory. This could lead to some performance issues.
- Service console memory: set the memory for ESX host to its maximum (800MB) to prevent running out of memory and having the Service Console to swap. Other option is to implement the ESXi version that does not require the configuration of the Service Console memory.
- Service Console swap partition: for the ESX hosts, configure 1600 MB partition for the Service Console swap or use the ESXi version to eliminate this.
- Nouniform Memory Access (NUMA) and settings in the host BIOS: for NUMA capable hosts like Intel Nehalem or AMD Opteron distribute the physical memory evenly between CPU’s. VMware ESX(i) is NUMA aware so you can disable the “Node Interleaving” feature in the BIOS.
- Host hardware type (rack mount vs. blade): compare the hardware aspects as scalability, modularity, flexibility, costs etc. Base the decision on those criteria’s.
- ESX software type (ESX/ESXi): In the future, the ESX version will be replaced by the ESXi version. ESXi is the way to go unless there are some hardware or software constraints like compatibility issues or management/back-up software agents.
- Host BIOS settings: for best performance, enable the Intel VT-x & EPT and AMD RVI & AMD-V settings in the BIOS. Enable Hyperthreading and Turbo Mode if the processor supports it. Disable unnecessary devices like serial, parallel, USB ports etc. Basically, turn off what you don’t need.
- PCI slot design for networking: consistent PCI slot assignment across all hosts is crucial if you plan to use automated installations or Host Profiles. It is easier to administer and simplifies troubleshooting.
- Power and cooling design: make sure that the datacenter where the new infrastructure will run has sufficient power and cooling capacity and all active components have redundant power supplies. This will prevent unnecessary downtime.
- Host name convention and IP addresses: to ease the management and administration use easy to understand host names and assign static IP addresses for the hosts. Register the name and IP address of the hosts in the DNS.
- Host security: From the security perspective, the best choice is the ESXi version. It has smaller attack surface but it also offers a lockdown mode. The other thing to consider is the firewall. The ESX has a build-in firewall, as ESXi requires an external firewall. Whatever the version, choose central management through vCenter Server. Limit the number of users that have root/administrator access. Limit the number of 3rd party agents that run on the Service Console or if possible move them to the vMA appliance.
OK, that was just day one. A lot of info to digest but it all makes sense and is interesting and good to know. Next blog post will cover day 2 of the course. Stay tuned!
Cheers!
– Marek.Z