Separating development and production servers: The original multi-tenancy

Today's converged infrastructure solutions combine network, server, and storage resources to a scale that may not be a good fit for every organization. IT pro Rick Vanover takes plays from the enterprise offerings to apply to smaller environments.

There’s no mistake that many of the offerings from the largest storage and server vendors is focused at the enterprise customer. For the smaller environment, that doesn’t mean that some of the design elements can’t be implemented into smaller architectures.

As a primer, multi-tenancy is intended to provide some form of isolation and flexibility across separate environments. In larger multi-tenancy configurations, this can be a separate server and storage infrastructure. For the smaller environment, to separate the storage fabric just can be cost-prohibitive. Historically, the most separated that many small environments would go is a development server. These systems may be connected to the same storage fabric that shares disk resources with production environments, however. Going the other direction, there can be a separate Active Directory domain for development environments.

Enterprise solutions such as 3PAR’s Virtual Domains or the joint effort by Cisco, NetApp and VMware to offer Secure Multi Tenancy (SMT) sticks the security moniker in the product, which has stirred debate from the competition. For the small and medium enterprise (SME), there may be fundamental investments that make these solutions out of reach.

What can the SME due to implement a well-designed multi-tenancy configuration? Basically spread the configuration as granularly as possible from the resources available or within reasonable acquisition cost. Here are some category examples for basic multi-tenancy separation:

  1. Storage:
  2. One domain of separation can be the drive tray. For modular storage systems, you can separate each logical unit number (LUN) so that a drive tray contains only development or production workloads. While the same controller may still be utilized, the modular storage can be separated at the tray level. This is increasingly relevant in consolidated environments using technologies such as VMware vSphere or Microsoft Hyper-V for virtualization.

  3. Servers:
  4. The long standing practice of separating development and production servers can be extended to include the rack (or cabinet). The logical unit associated with a development or production.

  5. Authentication:
  6. A separate Active Directory domain is a good realm of separation, but may be difficult to justify in some situations. If a separate domain that is not trusted to the primary domain cannot be implemented, a section of the primary domain with a totally different Group Policy and Organizational Unit configuration would be the next best option.

  7. Networking:
  8. Firewalls, VLANs, and IPSec rules can be utilized to implement separation from different workloads. This doesn’t necessarily require loads of new gear, as software firewalls such as Windows Firewall and Windows IPSeccan be centrally managed for free with Group Policy.

How do you apply a multi-dimensional approach to development and production separation for a multi-tenancy configuration? Share any of your additional steps below.