If you are a Windows administrator who is about to deploy their first Linux server, then you've got some big decisions that you will have to make as a part of the deployment process. Will users continue to be authenticated by the Active Directory, or are the Linux machines going to perform their own authentications? What will be the new server's role? What hardware will you need to achieve your intended goal? Needless to say, deploying one or more Linux Servers into a previously heterogeneous Windows environment is not an endeavor to be taken lightly. In this article, I will discuss some of the issues that you will need to consider when planning this deployment.
Before I begin
Before I get started, I just want to take a moment and give you a few words of caution. Introducing a Linux server into a heterogeneous Windows environment is a big step. Often in large companies, bringing Linux servers into a Windows environment isn't a matter of choice. Your company might buy out another company that uses Linux servers, or there may be an application that the company needs to run that can only be run on a Linux Server. These are perfectly legitimate reasons for deploying Linux.
On the other hand, I have known some administrators who have deployed Linux servers in a Windows environment just because it's a hip thing to do or because Linux servers are less expensive than Windows servers. If you are considering deploying a Linux server to fill a role that could just as easily be filled by a Windows server, you should really stop and think about the long term impact of your actions. Linux may be less expensive than Windows initially, but may ultimately cost the company more money in things like training for the administrative staff and in increased support cost. Of course these are just a few of the many issues that you will need to look at as a part of the planning process.
The most challenging aspect of writing an article regarding the planning behind introducing a Linux server into a Windows environment is that no two environments are exactly the same. Everyone's operational requirements are different, as are the reasons for using Linux. That being the case, it's impossible for me to write an article that gives you a step by step planning guide that is a specific match for your organization's individual requirements. Instead, I am going to talk about some of the things that you should think about prior to deploying Linux.
Defining the new server's role
When planning for any new server, whether it's going to be running Linux, Windows, or something else, one of the first things that you need to determine is how the server will fit into your existing organization. Initially, this means defining the scope of the server's role. For example, will the new server be an application server, a file server, an infrastructure server, or something else? Will the server be dedicated on one particular task, or will it be performing multiple roles?
Although defining the server's role is the first step in the planning process, it's often also the easiest step because you wouldn't even be thinking about purchasing a new server if you didn't have some kind of need.
Don't underestimate the importance of formally defining the server's role though. Yes, it's a good to have an idea of what you want to do with the new server, but formally defining the server's role is important for other reasons. For starters, server security is often role based. For example, you would approach server level security completely differently for a file server than you would for a Web server. If the server has a definite, defined purpose, it will make securing the server a whole lot easier than if the server is just hosting a variety of random services.
Defining a server's role is also extremely important when it comes to hardware planning. For example, let's pretend that the reason that you are deploying a Linux server is because your company needs to run a specific application that will not run on a Windows Server. The first thing that you would probably want to do is to figure out what server hardware is certified to work with Red Hat Enterprise Linux. To do so, check Red Hat's Hardware Compatibility List.
Once you have a good idea of what hardware is certified to work with the operating system, you would want to take the hardware requirements of the application into consideration. Don't just look at the minimum system requirements though. Most of the time, the minimum hardware requirements will allow you to install the application and to run it with a minimal feature set, but performance will be extremely poor. Instead, find out what kind of hardware the manufacturer recommends for optimal performance.
Once you are aware of the manufacturer's recommendations, plan for future growth. I recommend talking to the executives at your company to determine how many employees they expect to add over the next five years, and how many of those new employees will need access to the application. You can use those numbers to estimate disk space requirements, and the future requirements for things like CPU and memory resources.
Future planning is important because servers are a big investment and you don't want to outgrow your new server a year after purchasing it. Many times software manufacturers will base their hardware recommendations on the number of anticipated users. Therefore, if you can get someone at your company to estimate how many users will be accessing the server in five years and then increase that number by ten percent to give you a margin of safety, then you should be able to spec out hardware that will last you for at least five years.
One aspect of hardware planning that most administrators don't seem to think of is future growth in terms of additional tasks that the server may be asked to perform. For example, at one of my past jobs, I had to purchase a server that was going to be used to run a rather demanding accounting application. Although this particular application was Windows based, I went through a hardware planning process that was very similar to the one that I just described. Once I had collected all of the necessary information, I purchased a server that I knew would run the application in the necessary manner while allowing for the anticipated growth.
About four or five months later, my boss called me into his office and said that because of some new government requirement we were going to have to start running a new application. My boss at the time was one of those managers that is always trying to hold costs down, so he was insistent that I run the new application right along side the application that I had recently deployed on the new server. This is where having a formal definition of the server's role really paid off.
In reality, the server probably had enough resources to run the new application, but I didn't want to compromise the ability to accommodate future growth. Therefore, instead of agreeing to run the new application on the server, I showed my boss exactly how the server had been specked out. It was intended from day one to be a dedicated server hosting a specific application for up to a specific number of users. Being that I had this formal documentation in my possession, I was able to convince my boss that trying to piggyback another application onto the server was a bad idea, and managed to get the company to buy another server for the new application.
What will the server really cost?
I have talked a lot about the process of defining the new server's hardware requirements, but if you are thinking about deploying a Linux Server into a Windows environment, there are some other costs that you need to consider as well.
The primary expense aside from the initial hardware cost is training for the administrative staff. You need to consider things such as who will need training and what that training will cost. You also need to consider what would happen if one of the people that you train decides to leave the company. You may find yourself having to provide training for that employee's replacement. If you hire someone who is already trained in Windows and Linux, you may have to pay that employee more money than the employee that is being replaced was earning.
Nobody likes to think of these types of situations, but I have seen way too many real life cases of employees getting trained in something new and then going to get a better job that will pay them for their recent training. You have to anticipate something like this happening and plan for it.
Other potential expenses related to the new server are additional software licenses that may be required, and overtime pay for the IT staff during the implementation process.
Probably the toughest part of the planning process is figuring out exactly how the new Linux server will coexist with your Windows network. Unfortunately, I can't give you a lot of specifics here because everybody's network is different. Here is a list of questions that you should consider in regards to coexistence though:
- Will you use Samba to make the server look like a Windows Server?
- If so, how will the share structure be implemented, and who will have access to the new shares?
- Will using SAMBA require you to open ports in the firewalls that separate various segments of your network, or in the software firewalls that protect individual computers?
- Will you use the Active Directory to authenticate users who are accessing the Linux Server or will you use separate Linux based user accounts?
- If the Active Directory is going to be used to authenticate Linux users, how will you set up the necessary Kerberos authentication and LDAP access?
- Will the server accumulate data?
- If so, how will that data be backed up?
- Is your existing backup software Linux compatible?
- Does your existing backup hardware have enough capacity to backup the expected volume of data?
- Will you need additional licenses for your backup software?
- How will users access the new server?
- Will they use a UNC share?
- Will you be mapping a drive to a resource on the new server?
- Will the users even know what to do when they do access the new resource, or are they going to need training?
The implementation process
One last thing that I want to talk about is the implementation process. In the section above, I talked about some possible ways that your Linux Server might interface with your existing network. Although planning for coexistence is certainly important, you also have to consider how the initial implementation will affect your existing network.
If you are bringing in a Linux Server to host a new application, then the initial implementation probably won't have much of an effect on the existing network. If you are going to be migrating resources or applications from an existing server though, you need to plan for the down time that the migration process will cause.
One consideration is whether there are service level agreements that you need to adhere to. You may find that you are only able to have an application down for one hour on the second Tuesday of the month, or something crazy like that, due to contractual obligations.
Another consideration is your abort plan. I have done quite a few projects over the years that involve moving data or an application from one environment to another. Sometimes things go exactly as planned, and sometimes they don't. For example, one common issue is that file permissions tend to sometimes get messed up during a migration. As such it's very important to have an abort plan in place before you ever even begin the migration.
An abort plan is basically a plan that dictates how long you will spend trying to fix a catastrophic problem before giving up and bringing the old system back online. This is if the system is down, then users are unable to do their jobs. You need to know how much down time management will realistically tolerate and how long it will take you to put things back the way that they were before the migration. This will give you an idea of how long you can spend trying to fix a problem before you need to give up and start putting things back the way that they were.
Look before you leap
As you can see, there is a lot of planning that needs to happen prior to bringing a Linux server into a Windows environment. Unfortunately, I can't walk you through the entire planning process because everyone's network is different, but hopefully I have given you enough information to get you thinking about what types of planning you will need to do in your own environment.