Identity in the Dynamic Data Center

by Niel M. Bornstein

Most data center operators require all their servers to have static IP addresses (or they pin a dynamic address to a specific hardware address, which is essentially the same thing), and most also require them to have meaningful names. This makes a lot of sense for a number of reasons.

First of all, you don't want someone to be able to come along and plug in any old device into your data center network. After all, this is the pipe that's most likely to be pumping sensitive information between databases, mainframes, and web servers. By requiring a static IP or a whitelisted MAC address, you make it less likely (but not nearly impossible) for a rogue device to be able to access all the network configuration it needs.

Second, it's important that consumers of data center services always know how to connect to those services. Granted, this is becoming less important today as these services are more likely to be clustered and hidden behind switches. But a good data center operator always wants to know how to get directly to any of her boxes from a secure shell.

Third, speaking of secure shells, if a server ever does change its IP address or other aspects of its identity, you'll get an annoying but serious error message.

I'm sure there are many other reasons. And I hope some of my readers will share them with me.

The new thing is that resources in the dynamic data center can be created, provisioned, deprovisioned, and destroyed with no intervention from an operator; old policies about naming and addressing no longer apply. In the dynamic data center, virtual machines appear, do some work, and disappear on the fly. Depending on the virtualization system, a new VM may be assigned a random MAC address just before being loaded for the first time. There is no opportunity for an operator to assign a static IP address to a virtual machine or to configure a newly-created virtual MAC address in a DHCP whitelist.

Data center operators are going to need to change their view of the world. Systems management software vendors need to propose a better way.

4 Comments

Stephen Smoogen
2007-06-09 11:05:56
Or the dynamic data center might be the flying car of the computer center... nice to think about, can be built, impractical to work without some adjustments of the dreams of the driver.


For most centers you have to have some level of security, confidentiality, etc for the transactions to be trusted. Sure a virtual server could be built, 'provisioned', do its work, and be destroyed.. but if the work that it does can not be trusted.. it can be more of hazard than a boon. Because at some point it will be financially profitable for bad guys to inject bad bot systems (or have the ability to do so to blackmail or get protection money not to).


So you arent going to be able to randomly appear even if that is the easiest solution. Instead, the builder will have to request a centralized 'cookie' and will build various from those cookies. For a secure environmnet the transmissions would need to be on 'trusted' virtual networks with some sort of feedback loop so that the DHCP etc whitelists, kerberos keys, SSL certs, etc are sent back and forth.


If the speed of this secure provisioning is too slow.. then the dynamic systems may not be worth the 'bonus' they give. If the data from them is too 'un-trusted', then the data the virtual system gives will also be not worth the investment.

James Urquhart
2007-06-12 13:05:48
There are companies out there who are approaching IP/hostname assignment in a dynamic environment in a very different way than the virtual server guys. At least one vendor is assigning IP addresses to software payloads rather than individual physical or virtual server devices. Thus, DHCP is used to deliver an IP address to the device, but the booted server image always has the same IP address and/or hostname, regardless of which device it ends up running on.


This has the distinct advantage of allowing software to be decoupled from hardware entirely, yet the final image that runs on the server is almost exactly (is exactly) the same as if the software were hand installed on local disk by human operators.


Even virtual servers can take advantage of this approach, as they can be set to DHCP/PXE boot payloads with pre-assigned IP addresses. You get all of the consolidation advantages of virtualization, but you break the tight coupling between the software payload and the virtual server, which gives you most of the trouble that Neil talks about.

James Urquhart
2007-06-12 13:05:53
There are companies out there who are approaching IP/hostname assignment in a dynamic environment in a very different way than the virtual server guys. At least one vendor is assigning IP addresses to software payloads rather than individual physical or virtual server devices. Thus, DHCP is used to deliver an IP address to the device, but the booted server image always has the same IP address and/or hostname, regardless of which device it ends up running on.


This has the distinct advantage of allowing software to be decoupled from hardware entirely, yet the final image that runs on the server is almost exactly (is exactly) the same as if the software were hand installed on local disk by human operators.


Even virtual servers can take advantage of this approach, as they can be set to DHCP/PXE boot payloads with pre-assigned IP addresses. You get all of the consolidation advantages of virtualization, but you break the tight coupling between the software payload and the virtual server, which gives you most of the trouble that Neil talks about.

Jay
2007-06-19 07:40:31
There may also be issues in a Disaster Recovery / High Availability situation when moving machines across to geography boundaries, which may be represented by different networks.


Another issues we commonly have is that hostnames were typically based on physical machine and with the new dynamic nature of systems it's now much harder to know which (and what type) of platform a given system is running on.