...
We start by providing some samples for two main scenarios.
Services Model
This cluster of machines provides services. They do not specifically relate to each other.
Web Application Servers
example models and see how the naming works as the system evolves.
Web Application Model
Here is a fictional registration system that would be Internet facing. As such, it will require a web server and an application server. The budget is small so the database will also reside with the application.
Phase 1
The system starts small and begins with a registration system.
| Hostname | Description | Naming Convention |
|---|---|---|
| SO1 | Host system for Registration System | Use a 2-3 letter convention to describe the host's main function. In this case, we foresee the host system will be dedicated to small online applications. |
| RGH1V10WEB | Runs Apache Web Server | RG = Registration |
| RGH1V10APP | Runs Tomcat Application Server and HypSQL Database Server. | This has both an application and database. Because the database is portable and more easier to move, we make the judgment call to name the system APP after the more primary and long term function of the server. The convention follows but notice the V10. 10 = First virtual server for the specified function and it visually and via sorting will correspond to the Web Server. |
At this point the hostnames are not too bad. Their real value comes when the system needs to grow.
Phase 2
The system grows and requires a second host system and accompanying web and application server. Here is how it will look in a sorted list,
Services Model
This is an example of web and application servers that would grow over time.
| Hostname | Description |
|---|---|
| IM1 | Host system running VMs. IM standing for Identity Management |
| IMH1V1 | |
| IMH1V2 |
...
HyperSQL