Some way to uniquely identify multiple servers all hosting identical code?

sneakyimp

I'm working on a cloud-computing-type situation where I would like to bring multiple servers online in response to a fluctuating workload. I'm using Cloud Servers at rackspace.com and have saved a machine image representing one functional server. I'd like to bring online new instances of this server when there is a lot of work to be done and take them offline when there's nothing to be done.

I also want to have each server periodically check in with a central server to say "I'm still running". As each of these Cloud Servers will spawn with some PHP code that contains a username/password that permits access to the central server, this checkin can easily be accomplished by the Cloud Server inserting or updating a record in the centralized db with a timestamp that gets stored in a particular table (call it "helper_checkin" for now). I will then have a cron job on the central server that checks these timestamps

The problem I have is that if there are multiple servers checking in, I need a way to distinguish them from each other in such a way that the cron job running on the central server can grab all the records in the helper_checkin table and check the timestamp of each. If any particular timestamp is more than 15 minutes old, it's probably safe to say that the machine is no longer running and I would like to send a notification via email to tell me the Cloud Server has crashed. Obviously, this notification should clearly indicate to a sysadmin which machine has halted so that s/he can login and see what the problem is.

I'm leaning toward the hostname of each server as returned by [man]gethostname[/man] function. The problem with this is that these hostnames are not FQDN hostnames, but rather alphanumeric strings with some hyphens maybe. I'm not even sure they will be unique. I want to avoid having to put some unique string in the PHP code or file system of each server that gets spawned because this just seems like an extra step. The ideal situation would be that I could have some PHP function which returns the public-facing IP address of each Cloud Server (e.g., 50.57..) and not the IP address of the Cloud Server on the internal network (e.g., 10.181..). That would make it extremely easy to just login to the server in question and seek out the source of the problem. I've been looking around but none of these functions seem quite right.

Any thoughts would be much appreciated.

johanafm

One way would be exec('ifconfig', $output).

Another would be to have an external server with a script that returns the ip of the connecting machine.

sneakyimp

I had considered using ifconfig output but it also contains information related to packets exchanged that changes moment-to-moment.

root@image-grabber-2:~/Daemon/# diff 1.txt 2.txt
5,6c5,6
<           RX packets:69899493 errors:0 dropped:0 overruns:0 frame:0
<           TX packets:70426382 errors:0 dropped:0 overruns:0 carrier:0
---
          RX packets:69902947 errors:0 dropped:0 overruns:0 frame:0
          TX packets:70429932 errors:0 dropped:0 overruns:0 carrier:0
8c8
<           RX bytes:26839609710 (26.8 GB)  TX bytes:47688704117 (47.6 GB)
---
          RX bytes:26840924599 (26.8 GB)  TX bytes:47691287152 (47.6 GB)

The means of self-identification must be immutable over time. Additionally, I'd like the string that results to be short and concise. If I am running a script on my central db, the self-reported ID string of a given Cloud Server should fit in a varchar field and should allow a sysadmin to locate a machine based on this value. I suppose I could do some kind of preg_match on the ifconfig output, but was hoping there was some existing function that might work.

As for having an external server identify a Cloud Server by it's IP, that would be a cinch if the reporting machine were accessing a PHP script on the central server because I could use $_SERVER['REMOTE_ADDR']. Thanks for that thought. I may use that approach. It's more complex in that it requires an additional php script on the server which should authenticate the visitor and it also requires a curl script on the Cloud Server to report to the central server. I'm still kind of hoping for a self-reporting scheme.

bradgrafelman

Do you have access to an area of the file system that is not replicated among other cloud servers?

If not, try executing hostid and see if you get a response; if so, you might be able to use that value (although I'm not 100% what it represents and whether or not it would be cloned if a server was imaged).

sneakyimp

I believe when instantiating servers via the API that you can write a few files with whatever data you want. However, at this point discussions revolve around manual instantiation of these servers using the browser-based console. I.e., an individual would login and allocate a new server. Any additional file-writing would need to be done manually via ssh. Until we get a script set up, that is.

At any rate, hostid does appear to work on this machine but returns what looks like a hexadecimal value or hash. This would not be particularly useful to a sysadmin. I see that it appears to correspond to the ip address of the machine with some sort of byte reordering (big endian? little endian?) but it's not nearly as convenient as the actual IPV4 or IPV6 address.

I expect it will be pretty simply to parse ifconfig in this particular case as all instantiated machines will have the same distro (ubuntu) so I don't think we need to worry about different layouts for the ifconfig output. Still, i find it strange that PHP can't just ask the host machine what IP addresses it is bound to and get some structured result without all the extra mumbo jumbo.

Derokorian

Well you could have a function in your code to create a file if it doesn't already exist with the pertinent data. This file would be used to identify the server. Then when the server is "checking in" it would send this file for identifying purposes. That way as long as the server is there the file will exist but when it is freshly cloned it would make the file.

The downside to this of course, if that the new server would have to create the file, using resources, that may be better suited to handling the increased traffic that drove you to create the replication in the first place.