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

– All Developers across all groups within GSS Test – All QA engineers within GSS

– All QA engineers within GSS Stage – All production teams

– All production teams Production – All Production teams

– All Production teams Gregarious – All Dev, QA, and Production teams

Reservations

Development – Entire development cluster(s).

– Entire development cluster(s). Test – Will also consume the entire development cluster(s).

– Will also consume the entire development cluster(s). Stage – Entire stage cluster.

– Entire stage cluster. Production – Reservation for all production clusters. Assigned to the Production Group.

– 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

– Web Servers PCIAPP – Application Servers

– Application Servers PCIDB – Database Servers

SOX Compliance

SOXWEB – Web Servers

– Web Servers SOXAPP – Application Servers

– Application Servers SOXDB – Database Servers

No Compliance

NCWEB – Web Servers

– Web Servers NCAPP – Application Servers

– 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

– Web/APP Servers PCIDB – Database Servers

SOX Compliance

SOXGEN – Web/APP Servers

– Web/APP Servers SOXDB – Database Servers

No Compliance

NCGEN – Web/APP Servers

– 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.