10 Tips For Boosting Network Performance 256
snydeq writes "InfoWorld's Paul Venezia and Matt Prigge provide hands-on insights for increasing the efficiency of your organization's network. From losing the leased lines, to building a monster IT test lab on the cheap, to knowing how best to accelerate backups, each tip targets a typical, often overlooked IT bottleneck."
Switch to cable internet at work? (Score:2, Interesting)
Switching from Ts to Cable Internet service at work would get you fired within a week, since within that amount of time you will see downtime.
Backup to tape? (Score:2, Interesting)
Seriously, does anyone backup to tape anymore?
monitoring tools (Score:4, Interesting)
once I told a coworker about emule. He downloaded and installed it. The next morning the CFO comes to me.... "Have you ever heard about emule"...the infastructure was screwed up, but instead of fix it they waited for p2p to bring the network to it's knees. The best way to test a network is to see how many simultaneous p2p connections it can handle before crapping out. Needless to say there were some consequenced for that employee.
Re:Citrix/VDI/etc (Score:2, Interesting)
This is probably the first time I've seen the claim that thin clients _reduce_ network traffic.
Care to elaborate?
Re:2Base-TL (Score:5, Interesting)
For our US offices all we can get with a decent SLA is Factors of T1, we get Fiber/Ethernet service in Canada 10x faster for the same cost and SLA.
Re:Switch to cable internet at work? (Score:5, Interesting)
Re:Backup to tape? (Score:4, Interesting)
Re:For web servers (Score:1, Interesting)
Really? You've never heard of "print (pre)view"?
Re:11. (Score:3, Interesting)
Banning TCP/IP can help, in some circumstances. There are circumstances where shifting the resend mechanism out of the low-level protocol is actually the best option. This basically emulates TCP capabilities over UDP. (This has other advantages. You can multicast UDP, you can't multicast TCP, which helps sending the same data to multiple machines.) NACKing unreceived packets vs. ACKing the received ones also cuts bandwidth usage -- but you've got to be careful. Either the NACKs have to be sent via a reliable mechanism OR you have to send a NACK that is not attached to a packet number, otherwise there would be no way for the originating machine to distinguish between a dropped NACK and the recipient receiving all packets OK.
Re:Backups (Score:2, Interesting)
That's not /dev/null, that's a deleted file. /dev/null does *nothing* with anything written into it and attempting to read from it yields 0 characters read: source, around line 618 [kernel.org].
When however, you create a file, open, and delete it, then as long as your handle exists, the refcount of the inode won't reach zero and it won't be collected by the filesystem. This is a rather common practice.
Re:Backup to tape? (Score:4, Interesting)
You are right about tapes being more resilient, cheap and brought in a better form factor (not a minor concern; in fact that's what makes tapes the proper choice most times). But you are wrong in everything else.
"How do you backup TB's of data across many drives?"
Just exactly as you do with tapes.
"how do you ensure your disks dont get damaged on the ride to the bank/vault?"
By using careful transportation? Heck, if we can move a Ming dinasty jar all across the world, we can certainly move a bunch of SATA disks to the vault.
"today I sent out 9 LTO4 tapes (each holds upto 1.6TB) to the vault. I couldn't manage 9 disks."
You must be joking. 9 3.5" disks fit comfortably in a cardboard box protected with bubble plastic. Can't you manage *that*? Really?
"With tapes I just put them in the tape library and it manages everything itself"
Do you mean a cheap disk cabin wouldn't do the same? My two 15 SATA disks cabins must be a matter of magic, then.
"moves them around"
Of course your tape library moves the tapes around. That's because readers are so expensive that it only has one or two of them instead of fiveteen. Two 8 ports areca cards won't need to move any disk around: it gets enough ports to access all of them at the same time.
"knows which tape has what data, what can be overwritten, etc. Everyday it gives me a list of tapes to bring back from the vault and it gives me a list of tapes to take to the vault."
Exactly the same with disks, of course, since that's a matter of software, nothing physical media-related. Oh! and you'll get decent speed for random reads (like when recovering a single file) which you can't dream with tapes.
"The tapes cost about $40 each. A drive costs probably $1000."
A LTO4 probably will cost you more 50$ than 40$ but, anyway. Of course, a 2TB disk will cost you about 150$, not 1000$. The cost per GB is still on the side of tapes, but it's not sooo far from disks. And disks can be accessed randomly, and stand for read/write cycles orders of magnitude beyond tapes, so they are fastly coming to odds.
"My tape library cost like $10,000, it has two drives and holds around 40 tapes."
A SATA disk cabin will cost you about 1500$, holds 15 disks, will give you simultanous random access to all of them *and* will be easily upgraded to bigger disks when they become affordable.
Re:Real Tip #1 - Disable Interrupt Moderation on N (Score:5, Interesting)
Nice informative post, interrupt moderation sure sounds interesting. Link aggregation, however, is not as useful as it sounds for the following reasons:
1. Hardware link aggregation (link aggregation supported in silicon) works by hashing, not by distributing packets evenly across all links that are aggregated. If you can spare some time to ponder about this for a moment, you will be able to see why hashing is used. In real life situations, 4 x 1Gbps links aggregated together never equals 4Gbps throughput.
2. If link aggregation is handled by the software (which is most likely the case if aggregating multiple NICs on a server) then all it really provides is redundancy. It is very difficult for an average server to process 1Gbps of incoming traffic, let alone generate 1Gbps of worths of traffic. Not to mention the read/write speed of the storage device(s) used in the server.
(Unless it's using PCIE SSDs in RAID configuration, which would be very interesting and I am dying to find out the throughput of such a configuration!)
For once I actually know what I am talking about, so maybe I should have created an account before posting this one.
Re:Backup to tape? (Score:5, Interesting)
...and that's why offline HDD storage should equally be in RAID format.
That said, I worked for a D2D disaster recovery provider, and one time only we had issues recovering data from an archive drive due to disk failure. Suspicion was the drives were pulled before the job actually finished.
Now, HDDs sitting idle have a bit failure decay measured in years. Worst case, if the drive mechanism failes, the platters are still fully readable and easily recovered. Data being pulled from legal hold usually has no timeframe recovery requirements (unlike disaster recovery, there's no SLA for court requests of data), and worst case, HDD repair is a viable option.
Tapes have a bit failure rate measured in days, typically 30 for most tapes, and once data decays from the tape, it can not be recovered. Also, most typically, a tape recorded on one set of drives can not be read by another set of identical drives. often, the very same drive has trouble reading its own tapes if they've been shuffled out of the building and back in months later. I used to do an experiment in a classroom teaching DR methods where I'd perform a backup and bit-level verify (and only 3 in 10 pass verify at the bit level, but assuming it passed I'd continue, then I'd take the tape out of the drive, drop it just 6 inches to a table, flat, then put it back in the drive and repeat verify, and it would predictably fail 100% of the time. I'd repeat that with a hard disk backup of the same data set, let each person in the room drop the drive from shoulder height to the floor, then repeat the verify, and I never once had a failure (though once I had trouble getting the drive back in the tray slot).