Posted on by Sid Smith

Road to Automation with VMware vRA – vRA Design Part 1

Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)

GSS has decided on a number of design considerations for their vRA implementation.  GSS is currently using a consumption based model for their resource allocation.  They don’t pre-reserve any amount of resources for specific groups within the organization.  GSS feels their current consumption model allows them to more efficiently manage their resources.  It also prevents them from having pockets of idol resources that may never get used.  Based on this utilization model GSS will be implementing the following elements within vRA.

GSS  considered having a business group for each environment (Dev, Test, Stage, and Production).  To evaluate how they would like to proceed they asked to have 5 initial tenants created.  One for each of their environments and one to evaluate a collapsed model of all environments in one group.

Business Groups

  •  Development – All Developers across all groups within GSS
  • Test – All QA engineers within GSS
  • Stage – All production teams
  • Production – All Production teams
  • Gregarious – All Dev, QA, and Production teams

Reservations

  • Development – Entire development cluster(s).
  • Test –  Will also consume the entire development cluster(s).
  • Stage – Entire stage cluster.
  • Production – Reservation for all production clusters.  Assigned to the Production Group.
  • Gregarious – Will have reservations able o consume all clusters in their entirety.

* Overlapping reservations that can each fully consume all resources in a cluster will be configured to leverage over subscription and thereby be consumption based.

vSPhere DRS

DRS is used within each GSS cluster to group servers based on compliance and licensing.  The below DRS groups are utilized in each environment.  All deployments must be placed in their appropriate DRS Group.

PCI Compliance

  • PCIWIN – Windows Servers
  • PCILIN – Linux Servers
  • PCIDB – Database Servers

SOX Compliance

  • SOXWIN – Windows Servers
  • SOXLIN – Linux Servers
  • SOXDB – Database Servers

No Compliance

  • NCWIN – Windows Servers
  • NCLIN – Linux Servers
  • NCDB – Database Servers

Networks

Networks are also structured by compliance.and tiered based on server use.  Servers use is designed as web, app, or db server.

PCI Compliance

  • PCIWEB – Web Servers
  • PCIAPP – Application Servers
  • PCIDB – Database Servers

SOX Compliance

  • SOXWEB – Web Servers
  • SOXAPP – Application Servers
  • SOXDB – Database Servers

No Compliance

  • NCWEB – Web Servers
  • NCAPP – Application Servers
  • NCDB – Database Servers

Storage

As you may have already guessed, GSS is very serious about segregating systems for compliance reasons.  This extends to the storage architecture as well.  Systems are placed on storage based on compliance.  Web and App servers of the same compliance groups may share storage while database servers are segmented for performance reasons.

PCI Compliance

  • PCIGEN – Web/APP Servers
  • PCIDB – Database Servers

SOX Compliance

  • SOXGEN – Web/APP Servers
  • SOXDB – Database Servers

No Compliance

  • NCGEN – Web/APP Servers
  • NCDB – Database Servers

If you haven’t read up on the GSS – Gregarious Simulation Systems company profile you can catch up here.  In the next article we will dive in to the requirements GSS has regarding information to be collected from the requestor at the time of request.

Leave a Reply