What Goes into an Enterprise Network?
Komi asks: "I work for a big semiconductor company, and I'm part of a group that is spear heading the Linux movement here. Right now everyone uses Sun machines to design, but you can get a cheaper Linux x86 machine that is four times faster. So it is my job to prove that Linux works. The problem is that I'm an analog circuit designer stuck in the role of sysadmin. So I need some advice on what goes into a network. It won't be that large right now, but it has to be scalable for up to a couple of hundred machines. If this works, then hopefully we'll convince all designers at my company to make the switch."
"Here's the hardware that I am planning on getting:
- 2 servers:
These would hold the home accounts and tools, as well as serve out NIS, NTP, etc. I know I'll need a lot of hard drive space (2x72GB SCSI each), but do I need a lot of memory? (It's 4GB RDRAM max.) Should the processor be fast, or dual?
-
3 batch machines:
These would be a small compute farm running LFS or something. Jobs would get queued up and run continuously. So these should be dual CPU with lots of memory, probably 4GB each. Any other particular details?
- 10 desktop machines:
These would be on the designers and developers desktops. These should be reasonably fast (~2GHz) single CPU machines with probably need at least 2 GB RAM. The simulations we run do not benefit from dual CPUs. They probably don't even need SCSI. I'm thinking a $2k PC should work.
- 1 Itanium server:
This would be to play around on to test our 64-bit applications. The only advantage of 64-bit is applications using huge amounts of data.
What Goes into an Enterprise Network?
Dilithium?
Either this is the biggest troll ever, or you're deeply in the shit. Assuming it's the latter, for now, I shall toss my orb and see where it lands:
*HIRE A REALLY GOOD SYSADMIN*
You're horrendously out of your depth and there are shedloads of really good sysadmins around who need jobs. Take someone on for three months to look at the problem properly. Advice 2:
*DON'T BUY AN ITANIUM MACHINE*
There is simply no point, particularly if you don't really know what you're going to use it for.
Cheers,
Dave
I write a blog now, you should be afraid.
So I need some advice on what goes into a network. It won't be that large right now, but it has to be scalable for up to a couple of hundred machines.
...you can get a cheaper Linux x86 machine that is four times faster.
1) You had better find some damn fine PCs to replace those Suns, because a couple hundred PCs can make your life miserable due to lots of random breakage.
2) This is not true (unless you found Pentiums with SPECfp of over 3000!). If you buy the right-sized computers for your task, the hardware costs won't be a dominating part of your budget. Human costs and non-OS commercial licensing will be, regardless of your platform choice.
Whenever people say that Linux is absolutely outright cheaper then commercial UNIX, then I'm pretty convinced they haven't figured out all the costs involved. Also, I'm not convinced they understand just how simple maintaining a Solaris box can be, for example, due to sunsolve.sun.com, ample documentation, optional support out the wazoo, etc.
Before you go blazing these new trails, just stop and think for a minute. Put aside the zealotry and really think hard about what is and is not cost effective. Regardless of your choice, you really need to be convinced it is the right one.
Healthcare article at Kuro5hin
Your missing one metric which my company has found to be the most important!
QUALITY!
Because of the reduced price and increased performance of our DELL XEON boxes we are able to run more simulations on our circuits. This allows us to check a greater range of operating conditions thus improving the overall quality of our product.
One should not theorize before one has data. -Sherlock Holmes-
Never let Captain Kirk talk to the main computer. Every damn time he does he tricks it into self destructing. You'd think he doesn't want the Enterprise to have a network...
DAMMIT Jim! I'm a Doctor not a UNIX admin!
Well you have listed some trivial hardware requirements, what you haven't said are things like: 1) Does your application that the designers use to do their daily work exist on Linux, does it run as well, is as fully featured, cost the same amount of money... if the answer is NO then this is a non-starter 2) How are you going to handle signon, login, desktop managment, etc. 3) Backup is a big issue 4) Frankly 2 72 GB hard drives isn't enterprise or scalable. Look into RAID, LVM, and other options to make the hard drive system more reliable 5) The Linux solution isn't 4X cheaper, frankly it is significantly more expensive... you have all ready purchased the current solution correct, so the cost to maintain it is 0 (well not really but still) vs. having to buy this list of hardware and very possibly new software licenses (you have the solaris licenses right now correct, probably not Linux ones.. if they exist, see point 1) So the cost of this system going forward is significantly higher than the current solution Other than that, go for it... just remember it is much easier to tell you to spec it out and then say "We can't spend that kind of money" rather than tell you No up front
I have mod points and I am not afraid to use them
Now, back up and think about this:
In your case, you're talking primarily about engineers, and they are primarily (for job functions) going to be doing engineering
Now, on you EXISTING network, measure what a few users do for at least a few days. If you've got admin on, you should be able to extract information from the logs. This will give you a chance to get at how much load there really is.
Next task: establish some of your "non-functional" requirements. In particular, how long can response time be for your most important tools, how long can you afford to have the system as a whole be unavailable, and how much work (an hour, half a day, a week?) can you afford to lose. Divide all of those by two and make them your basic "service level agreement" -- which is simply a statement of the service you promise the users, it doesn't have to be fancy.
Here are some reasonable values, from experience, but YMMV: most people will put up with the whole system being unavailable for an hour, they want half-second response time from specialized tools and more like about 4 seconds on a web page, and engineers hate losing ANYTHING but usually don't get too pissed off if it's less than a couple of hours work and doesn't happen very often.
Next: what's the environment? Do you have to think about firewalling yourself from the rest of the network? (Don't assumme just because you're inside the corporate firewall that you're protected. Get AND READ the corporate security policy, as well as talking with the admins who own the network as a whole.) How will you do backups? How do you fit into the corporate disaster planning scheme? (Lots of people forget that one, but just look into what happened to the Wall Street Journal on 9/11 to see how essential it really is.) This analysis will give you a good idea what you need.
And now, having said all that, it will turn out that what you're going to need is (1) a "big enough" file server with 5/4 RAID and a good periodic backup onto "archival media" like tapes or writeable CDs; (2) one workstation good enough for all your applications, and with at least a years' room for growth, for each desktop (plan to buy at leasy one for a spare, and set it up "hot" so a single failure doesn't slow anyone down"); (3) a smallish box as a print server (if you manage your own email, it can often go onto this); and (4) a firewall box or a router (betcha 50 cents Canadian that the company will insist on this.)
Plan for a full week, plus one day per user workstation, for installation. That is, with 4 users, plan on 5 + 4 = 9 days for two people.
All the other stuff, like using NIS, NFS, Kerberos, etc, will more or less fall out if you get these steps right first.
I'm not a system admin but it seems like you are confusing two different battles:
1) Getting the whole company moved over to Linux for everything
2) Getting engineer workstations running on x86s so you can get 4x the speed.
(2) is a much easier battle to fight than (1). Don't spec a whole Linux solution for everything, spec out a Linux solution for the workstations that allows them to work with the Suns. There you can make the cost difference really obvious. Reliability isn't a big deal.... Your software vendor might even give you the test software in hopes of the license switch down the line. In the back of your mind you can keep the total Linux solution but your strategy should be to take out the Suns piece by piece by piece.
Total overhauls come down from above not up from below. Incrimental change that overtime turns into a total overhaul comes up from below. You don't sound like you have anywhere near the juice to get a total overhaul through the company regardless of how good your analysis is.
What I would concentrate in is:
Just a quick overview, to sum it up I would second the advice somebody else gave you in a previous posting: hire a decent sysadmin and plan things with him.
LOL...these are the type of people Windows admins have been putting up with for years, and now you *nix guys can start dealing with them.
"Hi, I was a desktop support tech, now I have been thrown into the job of managing our Windows network, how do I install that Active Directory thing?"
Windows has had the burnden of bad, inexperienced sysadmins for years, now Linux can share in the joy as it's more widely deployed.
ÕÕ