blog.virtualtacit.com

For any engineer that has deployed virtualized solutions, DMZ configurations are par for the course. Customers live and die by their presence and availability  on the web and you as a engineer should be versed in proper DMZ deployments. Not only to, most importantly, protect the customers internal data but to keep you and your companies name in good standing. As part of this new initiative toward security awareness and preventative maintenance, VMware has published a quick read on DMZ Virtualization with VMware Infrastructure, download here. What follows is a brief synopsis of the three most typical DMZ deployments in a virtualized environment:

• Partially Collapsed DMZ with Separate Physical Trust Zones
  • Zone separation achieved through independent clusters
  • Firewalls, IDS, IPS’s, etc. are physical devices requiring no change
  • All servers within each zone are virtual servers
  • Most common approach I have seen as it is the easiest. Network isolation is completely physical removing the need for VLANs.
  • Typically the approach that most larger organizations use, loose the benefit of resource consolidation, reduced power and cooling and all the other salubrious ends to virtualization
• Partially Collapsed DMZ with Virtual Separation of Trust Zones
  • This approach is a hybrid of sorts, layered between the SPTZ deployment and the DMZ in a box.
  • The virtual software is now a participant in the separation of security zones. Virtual switches corral which virtual servers can see which zones. The physical network devices are gatekeepers, controlling the security and communications between each zone.
  • Complexity level rises in such configurations although there is a greater balance between cost and resource utilization
• Fully Collapsed DMZ
  • Full DMZ in a box or host that is. Complete virtualization of all entities involved (ie.vServers, vSecurity appliances, vFirewalls, etc.)
  • Certainly the most complex of all configurations, user appropriation a must
  • Again full utilization of resources and low cost is a huge driver for this approach
  • Full auditing suggested across firewall and switches to maintain VM availability, especially in tandem with the advanced features of your VI (DRS, VMotion, etc)

To conclude, choosing the most apt DMZ design should ideally take into consideration the  number of physical NICs available, the customers internal security practices, as well as their tolerence for complexity. With this information in your back pocket and the developement of such programs as VMsafe , together we can snuff the negativity built around virtualization and security.

In addition, make sure to check out the following references as there is a lot of useful information geared toward securing virtual infrastructure.

• “VMware Infrastructure 3 Security Hardening”
  http://www.vmware.com/resources/techresources/726
• VMware Security Center
  http://www.vmware.com/security

If your looking for a EMC/VMware slant from the inside out then you got to check out VirtualGeek. From the foremost VMware expert within EMC, Chad Sakac, otherwise known as Mr. VMware has cannonballed into the blogging scene with some really cool posts as follows:

• 10 Gigabit Ethernet and VMware - A Match Made in Heaven
• So, how **EXACTLY** does VM HA’s admittance algorithm work?

Outside of his blog are a number of YouTube videos listed below…

• EMC & VMware: IP Storage-iSCSI, NFS, or Fibre Channel?
• Simple Acceleration of VMware Virtual Desktop Integration
• EMC & VMware: Tier 1 Application Availability & Flexibility

Keynote at this years EMCWorld..

• EMC World Keynote

His evangelistic approach is captivating and quite enjoyable, I suspect we’ll be hearing a lot from Chad. The industry will be listening, will you?

For those that missed it, a highly warranted document highlighting VI3 in Cisco environments was released a few weeks ago. Capturing such topics as vSwitch loop prevention, MDS port group selection, Native VLANs, and U/V shape Switch designs, to name a few. To my surprise there was no mention of VFrame, regardless this paper covers alot of ground and is a welcome addition. Enjoy…

http://www.vmware.com/files/pdf/vmi_cisco_network_environment.pdf

You be the judge. Great video supporting the casualness of celerra installs…

As part of a multi-part series I am working on, I decided it would be beneficial not only for me but for others to discuss the components built around Neverfail Heartbeat. To begin, Neverfail is a complex set of processes whose purpose is to provide high availability among windows based systems. It’s hardware agnostic and “shared nothing” design allow for a robust, multi-protection level solution. With that lets visit the first and probably most important piece to a successful implementation, pre-installation environmental data gathering via SCOPE.

Pre-Discussion Definitions:

• Primary Identity-refers to the physical hardware associated with the source production server in the pair. The Primary will always maintain its identity as the primary but can switch between the active and passive role.
• Secondary Identity-refers to the physical hardware associated with the destination or opposing server in the pair. The Secondary will always maintain its identity as the secondary but can switch between the passive and active role.
• Active Role-Server that is visible on the network, running the protected application and servicing client requests
• Passive Role-Standby server in the pair, receiver of replicated data from active server, and is not visible on the public network

Server Check, Optimization, and Performance Evaluation to be exact. This process in and of itself captures and reports on the following criteria:

1. Scrupulous information about your proposed HA server environment
2. Server optimization recommendations to support Neverfail products
3. Workload characteristics of said HA pairings
4. Bandwidth measurement requirements for WAN implementations

***Notably, you are required to run SCOPE prior to a production implementation to ensure environmental compatibility. In addition, installation support will not be given unless a SCOPE data collection has been run***

SCOPE must be run on both the primary and secondary before installation. Once complete the application will generate a CSV file (default location-C:\neverfail\scope\data\24 hour data) needed to create a NF license, obtainable from Neverfail’s Extranet site. Licenses for the HA pair are tied to the hardware ID of the primary server. If the following are changed on the primary, Neverfail Heartbeat will fail to start:

• Network Cards
• Processor
• MotherBoard

Note-Hardware changes on the secondary, whether or not it was active or passive, will have no effect on NF licensing. If the secondary ever needs to change to the primary then a new license key will need to be generated from the NF Extranet site using the SCOPE report from the secondary.

In our next session, we will look at additional pre-installation tasks and walk through the main points of installation.