Introduction

The VI3 Technical Design document is the output of all of the effort of transforming the VI3 Design Requirements via multiple technical workshops and other efforts, into one document that states the design decisions so that an architecture can be unambiguously blueprinted and implemented in the next, Implementing, stage.

Intended Audience

VMware Certified Professionals (VCP) and IT Architect/Designers during their design activities.

Outline

1. Reference to VI3 Requirements Specifications all Technical Workshops

2. High-level VI3 topology, including network and storage

3. ESX Server Host Design

4. Network Design

5. Storage Design

6. VirtualCenter Design

7. VirtualDatacenter Design

8. Resilience and Recovery Design

9. Monitoring Tools

10. Security Tools

11. Systems Management Tools

12. Capacity and Performance Objectives

The original technical requirements are located in VI3.Blueprint Requirements Specification.

(draw out all the technical requirements into a table here)

The high-level topology is logical, which means it shows the relationship of components but does not descend to the physical level to identify individual ports or other physical attributes.

(insert visio png here of the VC / VM / ESX / Network / Storage (fabric + array) / VCB / Converter here)

Each ESX Server host should meet the same design specifications, as stated below:

1. All hosts have the same configuration, except for individual identity information such as hostname and IP address. Other configurations such as vmnic/vSwitch configuration, should be identical.

2. Remote SSH logon is only allowed from the bastion host and not any other ESX host.

3. Remote SSH does not allow root user to logon - all users must logon with own ID and use 'sudo' to issue root-level commands

4. User accounts on ESX Hosts are restricted to individual operations staff accounts, and the passwords are synced with Active Directory.

5. IT Architects do not have access to any ESX host.

6. Local disk layout is as follows:

7. ESX Servers are not backed up.

8. ESX Servers are deployed using the CD install - future will include automated deployments, but manual only takes 20 mins and can be done completely within a four hour maintenance window.

9. All servers use NTP to the internal pool.ntp.acme.com servers

11. More TBD

Local disk layout

All ESX servers should follow the same local disk layout, which is set during installation.

The VI3 solution connects to three networks - internal, management and vmotion (non-routable).

Logical Network Diagram

(insert visio logical network design)

^{Logical Network Diagram}

• Key points about logical network design

Physical Network Diagram

(insert visio physical network design)

^{Physical Network Diagram}

The VI3 solution connects over fibre channel fabric to an EMC Clariion array.

Logical Storage Diagram

^{Logical Storage Diagram}

• Key points about logical storage diagram

Physical Storage Diagram

^{Physical Storage Diagram}

• Key points about physical storage diagram

The VirtualCenter server is the critical management component for the VI3 solution.

1. VirtualCenter is resilient by using Windows drivers for redundant NICs to the Management network.

2. The VirtualCenter server should be as stateless as possible, with all state data living off the box (e.g. remote database, mapped filestores).

3. The VirtualCenter database is on a remote database server, managed by the DBA team.

The VDC design is as follows:

1. All names for all configuration items use lower case

2. The datacenter that represents the VI3 solution (i.e. the VI3 solution is a virtual datacenter) is called s1vdc1 - Site 1, Virtual DataCenter 1.

3. There will be two Virtual Machine folders - one for ERP called "erp" and one for CRM called "crm".

4. Virtual machines will have the same name as the hostname set in the OS of that virtual machine. For new virtual machines, the naming standard will match the existing OS standards. There is no need to change the naming standard to reflect virtual machines, and certainly no need to put a "v" in the hostname!

5. The eight ESX servers in the solution will be placed into one cluster, which lives in s1vdc1, called cluster1.

6. There will be two resource pools in cluster1 - erp_pool and crm_pool.

7. Two user groups will be set up in Windows Active Directory—VM Operators and VM Administrators, and the users will have access via VI Client. End users of VMs will not have direct access using the VI Client.

8. Users in the VM Administrators group will be assigned the Administrator role. Users in the VM Operators group will be assigned the Virtual Machine Power User role, which restricts actions to only those on VMs and resource objects.

Resilience

Resilience is the ability to avoid business impact of a component failure and therefore maintain higher availability levels. For example, the web service can be said to be resilient to a NIC component failure when the web servers use redundant NICs and teaming software.

All infrastructure services should be resilient enough to withstand typical component failures (e.g. application process, OS BSOD/dump, NIC failure, disk failure) but not to the extreme of hard events like CPU failure or datacenter failure.

Before showing the component resilience it is important to not two operational approaches to resilience:

• Roles and responsibilities are tightly controlled and only limited staff have access to the server

• Maintenance is strictly enforced through change windows, reducing the chance of admin mistakes and making them more obvious to identify.

VirtualCenter is resilient because:

• The application process is set to restart if it stops because of an application process failure

• If the OS hangs, then HA will restart that VM on another host by HA.

• If the ESX server hangs/dies that is running the VC VM, then the VC VM will be restarted by HA on another host.

• Roles and responsibilities are tightly controlled and only limited staff have access to the server

• Maintenance is strictly enforced through change windows, reducing the chance of admin mistakes and making them more obvious to identify.

Virtual Machines are resilient because:

• All Virtual Machines are monitored by VMware HA and will be restarted if the OS or virtual machine fails.

• We are using standard process restarting agents inside the VMs to restart CRM and ERP processes

ESX Servers are resilient because:

• The ESX servers will have their workload restarted on other hosts should they fail, by HA.

Recovery

Recovery is the ability to recover from a serious failure that has impacted service. In this case, VCB is used to restore virtual machines that require recovery. ESX Hosts are simply rebuilt from scratch.

Monitoring of VI3 is via VC alerts pushed via SNMP up to the central alert aggregation solution.

No additional security tools required.

No additional systems management tools required.

Of the eight ESX servers, one is reserved for management software, introducing new servers and providing N+1 redundancy.

All ESX servers will use the default 70 Warning / 80 Critical warnings for CPU, Mem, Disk and Net alerts.