Except your first rule should be "Do not ever add additional services to operating servers". If you have so much excess server power that you can just randomly decide to make your Exchange server also be a DB server, then you should be using virtualization to partition these servers anyway so that it will be transparent that they are sharing hardware.
Just this weekend, my company had a data center move scheduled, one of the servers was thoroughly documented as only being an MS Project server for one department, and so the outage was arranged. After moving it, another unrelated application broke. It turned out that at some point someone needed a database and so they just went in the DC and found an underloaded server and installed SQL Server on it and configured a critical app from another department to talk to it. The server had to be moved *back* to its original location until an entirely new change management process could be initiated now that a new dependency was discovered.
Also, even if you really *have* to add additional functions to a server, there's no reason you can't create additional A records in DNS with appropriate functional names for the new functions. Then you can still move those services to their own server later if needed.
I don't think the specific standardized naming scheme you use matters that much, as long as you define something sensible for your location and stick with it. My last job our naming convention was along the lines of where LOC was the three-letter airport code of the nearest major airport to that office, DEP was the three letter department code of the department who owned the server, and then FUNCTION and NUM would be something like web01 or db03 or such. That system worked for us but I don't think there was anything magical or perfect about it.
Those were the official system hostnames. We almost always created additional DNS A records if it was a public facing server that needed a more memorable name. But even then we had long since abandoned any "fun" naming scheme. In the earlier years, we had three basic naming schemes. All my internal application servers were named after dog food brands (since we were "eating our own dog food") lab QA machines were named after breweries, and build servers were named after bands.
That last one generated an amusing complaint post-9/11. There was a build server named "anthrax", which had been named that for many years. After the anthrax incidents in the US, we received a complaint that the name was inappropriate.
But that was around the time we were adopting a more formalized naming scheme anyway. I tend to agree with others that fun/funny server names don't really give off a professional vibe. It's probably fine for universities and certainly for personal systems, but for business services these days, even a small starter mom-and-pop, I would keep the hostnames generically location and function based, with location not being any more specific than the general location. It's okay to need to change a hostname if a server is being moved from Chicago to New York (though I would prefer to just set up a new server in New York and migrate the services there) but you shouldn't have to rename a server just because it moved to a new rack or onto another floor.
There's also Project Management. I would think someone with a background in CS could take that knowledge and apply it usefully in managing development projects.
Personally, I would hate doing project management with a burning fire, but I will practically fall down and kiss the feet of a good project manager assigned to a project I'm assigned to.
All the great cars were built by automotive engineers, therefore cars can not be fun to drive.
Re:RAID5 is stupid, RAID 10 or no RAID
on
What NAS To Buy?
·
· Score: 1
RAID5 performance can be perfectly fine, it just depends on what your usage is and whether your hardware is designed right for it.
RAIDs 4 and 5 take a performance hit to writes, for example. This might not matter if you're usage isn't write-heavy, and it can be alleviated by using hardware with good write-cache (again, depending on your real usage patterns). For reads, RAID 4/5 should be competitive with the others since it can spread the reads across most of the spindles.
You can also squeeze more reliability out by using dual-parity if your hardware/software supports it.
The first thing you need to do when thinking about a NAS solution is prioritize your needs, specifically price, performance, and reliability. Different priorities in those areas will lead to different solutions.
Personally, I think the direction to look for low-cost, higher-reliability is big dumb servers with just a lot of directly-attached drives with no RAID controllers using ZFS. Sun's got a good start with the X4500 but it's still a bit too expensive, I think. I'd like to see cheaper commodity servers with the slots for a shit-ton of SATA drives and no money wasted on RAID controllers and write-cache that you don't need if you're performance needs aren't that high.
But that TCP flow control process is not instantaneous. And with bittorrent you are very likely to have a constant stream of new connections replacing old ones. Each new connection will attempt to start at full speed thus creating frequent little bursts of high incoming data before the dropped packets force retransmits and slower rates, no?
Does VOIP really use TCP usually? Shouldn't it be using UDP? Why would you want retransmits of lost packets during live voice conversations? I would think it would be better to just live with dropped packets than have the audio stream delayed by retransmits and such. Wouldn't that start to introduce more lag in the conversation?
I was just about to ask something along these lines. I couldn't find anything on their site actually documenting this as an ethernet cable.
Has anyone actually confirmed that this is just some kind of gussied-up Cat-6 cable or something? The most I could find on some quick searching was the Denon Link was it was a type of digital audio connector.
It's certainly ridiculously overpriced bullshit no matter what it is, but it seems like people are just assuming it's an ethernet cable because it looks like an ethernet cable.
It's a nice switch, but for goodness sake. This switch has been obsolete for at least three years!!! "The switch underwent three years of development, configuration and qualification testing before it journeyed into space."
If I was every to actually try something like this, this is exactly the kind of thing that I would try with ZFS first.
Not just for the simple software raid and all that, but for the automatic block checksumming, something I would be concerned about with a big pile of really old drives.
So why not make "Bulk" the default traffic classification and selectively identify the legitimate traffic that deserves higher priority? Now all bittorrent traffic is bulk no matter what port or encryption they use.
But Google has data centers distributed all over the world. The question would be does, say, the Chicago data center have a particular traffic pattern that is distinct from a data center in Shanghai or Greenland or wherever else Google might have DCs.
Coincidentally, I was at a ZFS talk recently, and the Sun employee giving the presentation was running some version of Solaris on her laptop, and it happened to pop up a warning about a CPU fault, but it was just a warning and the system kept working around it, albeit with some performance hit. The presenter mentioned it when it happened and claimed that Solaris was the only non-mainframe OS that would do this. A claim that I'm not informed enough to evaluate for accuracy, but certainly sounded suspicious.
(This was not a full "The CPU is on fire" type of failure, obviously. It was some sort of intermittent problem with a component or the bus or something I didn't understand. Supposedly after identifying the faulty component Solaris was simply working around it by doing extra work in software.)
Of course, it's not going to happen in the average corporation, where most involved parties prefer covering their ass by buying conventional branded products. It's not *just* ass-covering, although there's definitely some of that. Average corporations also do not *remotely* employ enough IT staff do be doing the sort of constant maintenance and replacements as Google is doing, not to mention the engineers doing testing and design of the specialized architecture, etc. And IT is often one of the first groups up against the wall when it's time to shore up numbers for the fiscal year.
I've worked with managers who believed very much in the commodity hardware philosophy, that they'd rather spend money on more technicians who can fix things than on support contracts with vendors. This is a laudable goal and one I wish could work reliably in many corporations, but it has one fatal flaw: Support contracts can't be laid off. As the annual corporate layoffs kept picking off more and more IT staff, and more and more IT work is transitioned to the Indian offices or wherever the next offshore hotspot will be, he gets stuck with machines basically built from off-brand parts and insufficient local support staff to keep up with the work of maintaining them, since what staff remains is also picking up all the other work from the laid-off employees.
And ironically, it's harder to get budget approval for support contracts after the fact. Also odds are good that the budget he got assigned 6 months ago didn't include costs of those support contracts.
Maybe? You tell me. I don't know what things someone might implement differently to make it not be a horrible experience for a person using non-Microsoft browsers and operating systems over WAN latencies, but the people theoretically responsible for championing the technology either didn't know or didn't care. All I know is I got tired of downloading bloated MS Office documents just to read a few lines of plain text.
Supposedly, much of Fermilab's current budget problems can be blamed on the retirement of Dennis Hastert. Haster's seniority and clout was a huge benefit for Fermilab. Apparently the timing of his retirement didn't help either, timed around the time that the budgets were being formulated and voted on. The actual budget vote that slashed Fermilab's funding didn't even get a vote from that district.
I don't know, maybe this just highlights how screwed up the congressional seniority system really is.
Seriously, what is the fucking deal with Sharepoint? Why do people really like this thing? At my last job we had just started making headway getting people to start using Wikis and then in comes the Sharepoint servers. The wikis get abandoned and now Sharepoint works great...for everyone using Windows and IE. Everyone using Macs, Linux, and Firefox tough luck.
Oh and every little department got their own Sharepoint site, which you needed to be separately granted access to, only they never remembered that and would constantly send out Sharepoint links that nobody else had permissions to access. And we had no cross-site search facilities (I assume *that* at least is possible, our people just didn't implement it) so if you didn't know which of a dozen different sharepoint sites your document was on, tough luck.
Yeah there's nothing I like better than wanting to look up a list of networks, which should be nothing more than a few lines of text, but instead I get to download an MS Word document or an Excel Spreadsheet and load up the respective clients, in my browser, from my office 2,000 miles away from the Sharepoint server. Several minutes later I can now read a dozen lines of plain text! WOOO!
This was true of most of Africa as well. Africa used to have a much more diverse tribal population, but most of them were over time replaced by a few more aggressive groups, long before the white people arrived and began dabbling in free labor sources.
Long-distance passenger trains in the US are frequently delayed because of passenger freight, which they must defer to, since in most cases the rail lines are owned and operated by the freight companies. (Other countries typically the national rail service owns and operates the rail lines and the passenger service.)
But in contract, I recently took the train from Chicago to Milwaukee airport. The whole trip took less then 90 minutes, which is faster than any car or bus can make it under normal traffic conditions.
I don't think train travel will ever be able to be truly cheaper than air travel for long distance though (in the US). There's too much competition and demand in air travel keeping prices down and not enough people willing to take a multi-day train trip at all, much less at any remotely profitable price.
If for whatever reason you don't feel like taking the time to properly classify the problem packets, or if said housemate might be someone inclined to try and sneak around such things by tweaking his bittorrent settings, one simpler approach is to make all traffic lowest priority by default, and then you specifically define the important traffic to be higher priority. Just don't forget the really important stuff but sometimes less obvious stuff like DNS traffic.
Of course if you REALLY want to simply deal with just the housemate, you could always identify his traffic by his MAC address and just bump all of his traffic down to low priority.
It's certainly taught to me than once (not as a manager) that it is good security policy to do this for terminated IT employees. I suspect some companies just don't make a distinction between terminated employees and employees leaving voluntarily.
At one of my old jobs, I remember them doing this specifically in the case where they found out the employee was going to a competitor.
Just speaking for myself, when I was running DD-WRT it would lock up every few days requiring a reboot. I finally just put a scheduled daily reboot in cron and it worked mostly fine after that, though it did have one or two lockups still over the course of a couple months.
I eventually switched to tomato for better QoS support and tomato has been rock solid.
It also seemed like dd-wrt development wasn't progressing very much, as there hadn't been an update in quite a while. Though I do note now that they finally made v24 an official release just recently, so things may have improved since then.
DD-WRT does have some features that tomato doesn't, though. If I needed any of those features I wouldn't hesitate using DD-WRT again. Though I might try OpenWRT first just because I haven't tried it yet.
Slashdot Mirror
Except your first rule should be "Do not ever add additional services to operating servers". If you have so much excess server power that you can just randomly decide to make your Exchange server also be a DB server, then you should be using virtualization to partition these servers anyway so that it will be transparent that they are sharing hardware.
Just this weekend, my company had a data center move scheduled, one of the servers was thoroughly documented as only being an MS Project server for one department, and so the outage was arranged. After moving it, another unrelated application broke. It turned out that at some point someone needed a database and so they just went in the DC and found an underloaded server and installed SQL Server on it and configured a critical app from another department to talk to it. The server had to be moved *back* to its original location until an entirely new change management process could be initiated now that a new dependency was discovered.
Also, even if you really *have* to add additional functions to a server, there's no reason you can't create additional A records in DNS with appropriate functional names for the new functions. Then you can still move those services to their own server later if needed.
I don't think the specific standardized naming scheme you use matters that much, as long as you define something sensible for your location and stick with it. My last job our naming convention was along the lines of where LOC was the three-letter airport code of the nearest major airport to that office, DEP was the three letter department code of the department who owned the server, and then FUNCTION and NUM would be something like web01 or db03 or such. That system worked for us but I don't think there was anything magical or perfect about it.
Those were the official system hostnames. We almost always created additional DNS A records if it was a public facing server that needed a more memorable name. But even then we had long since abandoned any "fun" naming scheme. In the earlier years, we had three basic naming schemes. All my internal application servers were named after dog food brands (since we were "eating our own dog food") lab QA machines were named after breweries, and build servers were named after bands.
That last one generated an amusing complaint post-9/11. There was a build server named "anthrax", which had been named that for many years. After the anthrax incidents in the US, we received a complaint that the name was inappropriate.
But that was around the time we were adopting a more formalized naming scheme anyway. I tend to agree with others that fun/funny server names don't really give off a professional vibe. It's probably fine for universities and certainly for personal systems, but for business services these days, even a small starter mom-and-pop, I would keep the hostnames generically location and function based, with location not being any more specific than the general location. It's okay to need to change a hostname if a server is being moved from Chicago to New York (though I would prefer to just set up a new server in New York and migrate the services there) but you shouldn't have to rename a server just because it moved to a new rack or onto another floor.
There's also Project Management. I would think someone with a background in CS could take that knowledge and apply it usefully in managing development projects.
Personally, I would hate doing project management with a burning fire, but I will practically fall down and kiss the feet of a good project manager assigned to a project I'm assigned to.
All the great cars were built by automotive engineers, therefore cars can not be fun to drive.
RAID5 performance can be perfectly fine, it just depends on what your usage is and whether your hardware is designed right for it.
RAIDs 4 and 5 take a performance hit to writes, for example. This might not matter if you're usage isn't write-heavy, and it can be alleviated by using hardware with good write-cache (again, depending on your real usage patterns). For reads, RAID 4/5 should be competitive with the others since it can spread the reads across most of the spindles.
You can also squeeze more reliability out by using dual-parity if your hardware/software supports it.
The first thing you need to do when thinking about a NAS solution is prioritize your needs, specifically price, performance, and reliability. Different priorities in those areas will lead to different solutions.
Personally, I think the direction to look for low-cost, higher-reliability is big dumb servers with just a lot of directly-attached drives with no RAID controllers using ZFS. Sun's got a good start with the X4500 but it's still a bit too expensive, I think. I'd like to see cheaper commodity servers with the slots for a shit-ton of SATA drives and no money wasted on RAID controllers and write-cache that you don't need if you're performance needs aren't that high.
But that TCP flow control process is not instantaneous. And with bittorrent you are very likely to have a constant stream of new connections replacing old ones. Each new connection will attempt to start at full speed thus creating frequent little bursts of high incoming data before the dropped packets force retransmits and slower rates, no?
Does VOIP really use TCP usually? Shouldn't it be using UDP? Why would you want retransmits of lost packets during live voice conversations? I would think it would be better to just live with dropped packets than have the audio stream delayed by retransmits and such. Wouldn't that start to introduce more lag in the conversation?
I was just about to ask something along these lines. I couldn't find anything on their site actually documenting this as an ethernet cable.
Has anyone actually confirmed that this is just some kind of gussied-up Cat-6 cable or something? The most I could find on some quick searching was the Denon Link was it was a type of digital audio connector.
It's certainly ridiculously overpriced bullshit no matter what it is, but it seems like people are just assuming it's an ethernet cable because it looks like an ethernet cable.
If I was every to actually try something like this, this is exactly the kind of thing that I would try with ZFS first.
Not just for the simple software raid and all that, but for the automatic block checksumming, something I would be concerned about with a big pile of really old drives.
So why not make "Bulk" the default traffic classification and selectively identify the legitimate traffic that deserves higher priority? Now all bittorrent traffic is bulk no matter what port or encryption they use.
But Google has data centers distributed all over the world. The question would be does, say, the Chicago data center have a particular traffic pattern that is distinct from a data center in Shanghai or Greenland or wherever else Google might have DCs.
Coincidentally, I was at a ZFS talk recently, and the Sun employee giving the presentation was running some version of Solaris on her laptop, and it happened to pop up a warning about a CPU fault, but it was just a warning and the system kept working around it, albeit with some performance hit. The presenter mentioned it when it happened and claimed that Solaris was the only non-mainframe OS that would do this. A claim that I'm not informed enough to evaluate for accuracy, but certainly sounded suspicious.
(This was not a full "The CPU is on fire" type of failure, obviously. It was some sort of intermittent problem with a component or the bus or something I didn't understand. Supposedly after identifying the faulty component Solaris was simply working around it by doing extra work in software.)
I've worked with managers who believed very much in the commodity hardware philosophy, that they'd rather spend money on more technicians who can fix things than on support contracts with vendors. This is a laudable goal and one I wish could work reliably in many corporations, but it has one fatal flaw: Support contracts can't be laid off. As the annual corporate layoffs kept picking off more and more IT staff, and more and more IT work is transitioned to the Indian offices or wherever the next offshore hotspot will be, he gets stuck with machines basically built from off-brand parts and insufficient local support staff to keep up with the work of maintaining them, since what staff remains is also picking up all the other work from the laid-off employees.
And ironically, it's harder to get budget approval for support contracts after the fact. Also odds are good that the budget he got assigned 6 months ago didn't include costs of those support contracts.
What non-free software does gNewSense still contain?
Also http://www.youtube.com/watch?v=gUYWGo4Fl2s
Maybe? You tell me. I don't know what things someone might implement differently to make it not be a horrible experience for a person using non-Microsoft browsers and operating systems over WAN latencies, but the people theoretically responsible for championing the technology either didn't know or didn't care. All I know is I got tired of downloading bloated MS Office documents just to read a few lines of plain text.
Supposedly, much of Fermilab's current budget problems can be blamed on the retirement of Dennis Hastert. Haster's seniority and clout was a huge benefit for Fermilab. Apparently the timing of his retirement didn't help either, timed around the time that the budgets were being formulated and voted on. The actual budget vote that slashed Fermilab's funding didn't even get a vote from that district.
I don't know, maybe this just highlights how screwed up the congressional seniority system really is.
Seriously, what is the fucking deal with Sharepoint? Why do people really like this thing? At my last job we had just started making headway getting people to start using Wikis and then in comes the Sharepoint servers. The wikis get abandoned and now Sharepoint works great...for everyone using Windows and IE. Everyone using Macs, Linux, and Firefox tough luck.
Oh and every little department got their own Sharepoint site, which you needed to be separately granted access to, only they never remembered that and would constantly send out Sharepoint links that nobody else had permissions to access. And we had no cross-site search facilities (I assume *that* at least is possible, our people just didn't implement it) so if you didn't know which of a dozen different sharepoint sites your document was on, tough luck.
Yeah there's nothing I like better than wanting to look up a list of networks, which should be nothing more than a few lines of text, but instead I get to download an MS Word document or an Excel Spreadsheet and load up the respective clients, in my browser, from my office 2,000 miles away from the Sharepoint server. Several minutes later I can now read a dozen lines of plain text! WOOO!
Thanks, Bill!
This was true of most of Africa as well. Africa used to have a much more diverse tribal population, but most of them were over time replaced by a few more aggressive groups, long before the white people arrived and began dabbling in free labor sources.
Long-distance passenger trains in the US are frequently delayed because of passenger freight, which they must defer to, since in most cases the rail lines are owned and operated by the freight companies. (Other countries typically the national rail service owns and operates the rail lines and the passenger service.)
But in contract, I recently took the train from Chicago to Milwaukee airport. The whole trip took less then 90 minutes, which is faster than any car or bus can make it under normal traffic conditions.
I don't think train travel will ever be able to be truly cheaper than air travel for long distance though (in the US). There's too much competition and demand in air travel keeping prices down and not enough people willing to take a multi-day train trip at all, much less at any remotely profitable price.
If you think Obama or Hillary are real liberals and/or socialists, you REALLY need to meet some real liberals and socialists.
Beer *distributor*, not brewer.
http://www.abwholesaler.com/hensley/ProductList
Short answer: Mostly junky.
If for whatever reason you don't feel like taking the time to properly classify the problem packets, or if said housemate might be someone inclined to try and sneak around such things by tweaking his bittorrent settings, one simpler approach is to make all traffic lowest priority by default, and then you specifically define the important traffic to be higher priority. Just don't forget the really important stuff but sometimes less obvious stuff like DNS traffic.
Of course if you REALLY want to simply deal with just the housemate, you could always identify his traffic by his MAC address and just bump all of his traffic down to low priority.
It's certainly taught to me than once (not as a manager) that it is good security policy to do this for terminated IT employees. I suspect some companies just don't make a distinction between terminated employees and employees leaving voluntarily.
At one of my old jobs, I remember them doing this specifically in the case where they found out the employee was going to a competitor.
Just speaking for myself, when I was running DD-WRT it would lock up every few days requiring a reboot. I finally just put a scheduled daily reboot in cron and it worked mostly fine after that, though it did have one or two lockups still over the course of a couple months.
I eventually switched to tomato for better QoS support and tomato has been rock solid.
It also seemed like dd-wrt development wasn't progressing very much, as there hadn't been an update in quite a while. Though I do note now that they finally made v24 an official release just recently, so things may have improved since then.
DD-WRT does have some features that tomato doesn't, though. If I needed any of those features I wouldn't hesitate using DD-WRT again. Though I might try OpenWRT first just because I haven't tried it yet.