On the Software Defined Data Center
Yeh I know… it’s one of the US spellings I actually like.
I guess this all kicked off a few days ago, with this tweet:
RT @theronconrey: I know this is going to sound like heresy but when hasn’t the datacenter been defined by software? < +1
— Stuart Radnidge (@sturadnidge) August 27, 2012
Don’t take the following too literally… you can of course take the scenario to the nth degree, I’ve tried to strike a balance between too much detail and not enough.
It’s really just something to think about. Something I think about.
—-
A server arrives at the datacenter. An hour later it’s in service and being used.
A server arrives at the datacenter. A facilities member removes the packaging, slaps on a QR code sticker then scans it into the inventory management system. A few milliseconds later a rack location is returned from the inventory management system. Less than an hour later, the server has ping and power. Shortly after that, it’s in service and being used.
A server arrives at the datacenter. A facilities member removes the packaging, slaps on a QR code sticker then scans it into the inventory management system along with the asset tag provided by the server manufacturer and the burn-in confirmation tag provided by the server assembly company. A few milliseconds later a rack location is returned from the inventory management system. Less than an hour later, the server has ping and power. After power on self test, the BIOS initiates a PXE boot sequence. The server provisioning system delivers the relevant operating system installer to the server. The application configuration management system delivers the relevant application dependencies, binaries, code and configuration to the server. Shortly after that, the server is in production and being used.
A server arrives at the datacenter. A facilities member removes the packaging, slaps on a QR code sticker then scans it into the inventory management system along with the asset tag provided by the server manufacturer and the burn-in confirmation tag provided by the server assembly company. A few milliseconds later a rack location is returned from the inventory management system, which made a placement decision based on the environmental conditions of the facility and a few of the requirements found in the originating request for the server. Less than an hour later, the server has ping and power. After power on self test, the BIOS initiates a PXE boot sequence. The broadcast packet hits a switch, which fires an event to the network control system, having never seen the endpoint before. Since it’s a DHCP request, a default rule allows the packet to be forwarded to a router, while the network control system asynchronously queries the configuration management service for instructions on how to configure the access port / data flows for future non-DHCP traffic. The router relays the request to a DHCP server, which examines the options in the request. Upon finding the PXE option, it fires off a request for the boot image location to the server provisioning system and returns an IP address and boot image location to the server. The server, having obtained an IP address, requests the boot image from the server provisioning system. The server provisioning system, having never spoken to a server with this UUID before, sends a pre-OS environment to the server. The pre-OS environment boots, enumerates the hardware and determines some BIOS options and firmware version are out of policy. It applies the correct firmware profile, checks that the BIOS is configured to PXE boot, sends a completion message to the server provisioning system and reboots the server. After POST, a DHCP broadcast is sent again. The switch knows how to handle the request this time and does not need to query the network control system again. The same IP address and boot image location are sent from the DHCP server. When the boot image is requested, the server provisioning system moves to the next step in the provisioning workflow, and delivers the relevant operating system installer to the server. After the OS install has completed, which may have actually not been an install at all but merely the network boot of an in-memory OS, the system management agent contacts the infrastructure configuration management system, which it auto-discovered via a DNS SRV record, and requests the required monitoring, backup and system assurance configurations. The infrastructure management system makes the necessary requests for registration and configuration data from each of the supporting infrastructure services, which it then returns to the system management agent, which in turn applies the configuration then sends a message to the application configuration management system and puts itself to sleep. The application management agent, which also located it’s nearest configuration management system via DNS and phoned home some time ago only to be told it had nothing to do, is awakened from sleep by a notification from the application configuration management system. The application configuration management system delivers the relevant application dependencies, binaries, code and configuration to the server, which were defined at the same time that the compute capacity was ordered - neither of which were done by a human. Shortly after that, the server is in production and being used.
—-
Datacenters have always been, or at least always had the ability to be, defined by software - virtualisation is not a pre-requisite, although I would argue it took virtualisation to make a significant number of people think about infrastructure wholistically.
As William Gibson said, “The future is already here — it’s just not very evenly distributed.” Maybe all we’ve been missing is wholistic thinking about the problem outside of the Googles, Amazons and Facebooks of the world.
