In data center networking, you really don’t care what is hosted on a server. Let’s face it. You know it’s true. Some business unit probably calls this app “critical”. It probably generates a report that 3 people in the company see. But it’s important to them.
To you, it’s a VLAN, an IP address, a port number, and/or a firewall rule. You may even know a bit more about it and throw some IPS at the traffic coming from it. Why are there so many servers!?! Why not just put a database and web server on the same machine? It would be way easier, and make your life as a network engineer way more simple. But there are a few reasons why the data center has “web servers”, “database servers”, “app servers”, “storage arrays”, etc.
Server guys segment the responsibilities for multiple reasons. Here are a few:
- Ease of operation
- Application Resiliency
- Application Redundancy
- Processing Power
Ease of operation
Let’s say you’re a server administrator and you’re in charge of 100 servers. These servers aren’t like networking equipment. As a network administrator, the only people allowed to log into your equipment are other qualified network gurus. Server admins aren’t so lucky. They have to allow programmers, scripting hackers, app developers, and all kinds of seedy, nefarious sorts into their devices….. (shiver).
If they only allow one app per server, which is incredibly easy to do with virtual servers these days, they can reduce the amount of conflict with all the users logging in. Their web developers will log into the relevant web servers, their database developers will log into their database servers, and so on. This way a DBA with root access won’t kill an App being developed by another team.
You’ve seen it on Windows, you’ve seen it on Mac, and you’ve seen it on Linux. Some apps just don’t play nice. When you have business critical applications, separating them into silos makes perfect sense. When a server is only running Apache, you don’t have to worry about an Oracle database conflicting with it.
Updates are another HUGE reason for segmenting servers. If you’re updating your database applications, you’ll most likely have to reboot the box. If you’re running a web server, development server, and application server on the same box, you’ve effectively killed 4 birds with 1 stone. THIS IS NOT A GOOD THING IN INFORMATION TECHNOLOGY! 🙂
When you have a server dedicated to one purpose, you can easily replicate that process. In fact, many server applications were designed to be run in “clusters” or redundant modes. If the application server is the only thing changing on the box, you can easily sync those changes between multiple servers. You could go old school with rsync and vmotion or a more modern take on distributed application processing. Either way, keeping the server segmented helps mitigate problems you could run into when syncing server functionality between multiple physical/logical servers.
In the same vein as redundancy, when you go the more modern distributed processing route, you are utilizing multiple server processors for the same functionality. You’re load balancing your processing across multiple systems.
Have you ever gone to a website and typed www.blahblahxyz.com and had your browser redirect to ww2.blahblahxyz.com? ww2 is a different server than ww3 and ww4 and so on. They’re all hosting the same software, but a load balancer is distributing the load between multiple instances of the same segmented server.
I recently got burned on this one. I was running a LAMP server. Linux, Apache, Mysql, PHP server. I didn’t segment my web server and my mysql server. I opened up my mysql port and within 10 days, my server was slowing to a crawl. Hackers were DOS-ing the mysql port of my server. My own web server couldn’t load pages or even access the database residing on the same box. I could have just closed the port and been done with it, but I moved the database server to another VM. The instant I moved the server to another VM, my web server woke back up and started processing requests.
When you segment servers, you inherently secure your servers. If one application is compromised, that typically means the whole server is. If that application is the only application on the server, you’re not losing multiple hosted solutions because of one compromised application.