Choosing a data center is a big decision for most companies. Your IT infrastructure represents a critical asset for your company, and unless you are an uber-dot com company like Google or Facebook (which spread their gear around the country in tens of locations), you probably only have one or two data centers. Changing data centers is expensive and time consuming, so choosing the right data center partner is incredibly important.
Unfortunately, data centers don’t make it easy on you to differentiate between them. Everyone says they are “secure,” “highly available,” and “high density.” They all show you their generator farms, their battery rooms, and their security vestibules with bullet proof glass. Tour any three data centers and you’ll be left scratching your head trying to figure out what the difference is. As a result, many people end up using price and proximity as the primary decision points. Or even worse, they look at non-material amenities like free sodas and xboxes in the break room as the deciding factor.
There are critical differences, however, between data centers. Failing to recognize them can cost you more in the long run than any savings you might glean by choosing the low-cost provider. Having purchased services from a multitude of data centers over the last two decades, and having dealt with even more as an IT consultant, I’ve learned to recognize some of the hard to spot differences that can make or break a long term data center relationship. For simplicity (so you can copy/paste into your next RFP), I’ve listed the 10 questions you should ask your next data center below. A detailed explanation of each question follows, so you know what you should look for. I hope you find this list informative.
10 questions to ask your next data center provider
Which components of the data center facility are both fault tolerant and concurrently maintainable?
How are cooling zones provisioned to maintain operating temperatures during maintenance or failures of CRAC/CRAH units?
What are the average and maximum power densities of the facility on a watts/sq’ and watts/cabinet basis?
How often does the data center load test its generators?
What are the highest risk natural disasters for the area, and what has the data center done to mitigate their impact?
What are the minimum skill sets of the remote hands and eyes staff?
Does the data center maintain multiple redundant sources of fuel and water?
What certifications has the data center earned, and do they undergo annual audits to maintain them?
How does the data center track SLA compliance, and what is their historical track record? Can they provide their last 5 failure reports?
What is the profile of their top 5 clients, and what percentage of total revenue for the facility do they represent? (read more…)
In part 1 of this series, I established the problem latency can cause in high speed networks. What one reader correctly referred to as “big long pipes.” To summarize, in large bandwidth networks that span long distances, network latency becomes the bottleneck that retards performance. The reason for this the impact of network delays on TCP windowing. In part, 2 I will discuss what to do about it.
Dealing with latency can be tricky business. The methods used to mitigate the impact of distance depends on many factors including the services being accessed, the protocols being used, and the amount of money you want to spend. What works for a home user does not work for a multi-national corporation. In general, there are 4 approaches one can take to deal with latency:
Tweak the host TCP settings
Change the protocol
Move the service closer to the user
Use a network accelerator
The first and least effective method is to tweak the TCP settings on your hosts. I say least effective for several reasons: It is hard to determine the correct TCP window size; not all operating systems support the RFC 1323 extensions; you may not have control of all the hosts; available bandwidth may change due to network congestion. Most importantly, some time sensitive applications such as VOIP will still exhibit problems in high latent networks, even if you tweak TCP. Still, if you are a home user on a big long pipe, this is the only option for you. Changing TCP is OS specific. Slaptijack.com has an excellent series on TCP tuning operating systems. Below are links to his specific guides as well as other sources: (read more…)
One concept that continues to elude many IT managers is the impact of latency on network design. 11 years ago, Stuart Cheshire wrote a detailed analysis on the difference between bandwidth and latency ISP links. Over a decade later, his writings are still relevant. Latency, not bandwidth, is often the key to network speed (or lack thereof).
I was reminded of Cheshire’s article and the underlying principles recently when working on an international WAN design. What Cheshire noted was that light signals pass through fibre optics at roughly 66% of the speed of light, or 200*10^6 m/s. Regardless of the equipment or protocols you use, your data cannot exceed that theoretical limit. This limit equals the delay between when a packet is sent, and when it is received, aka latency.
In the US, we tend to focus on bandwidth and carrier technology when ordering circuits, completely ignoring latency. For instance, when choosing between cable and DSL for your house do you ever ask the carrier for its latency SLA? Maybe you should. Using a cable connection a ping to www.google.com in Mountain View, CA from my house (137 KM) yields an average ping time (aka round-trip time or RTT) of 73ms. The theoretical latency for this distance (round trip) is 1.37ms meaning my cable connection is roughly 50 times worse than the theoretical limit. No surprise that Comcast focuses on bandwidth and not latency in its marketing. (read more…)
Recently, I was evaluating ISP’s for my hosting requirements. If you take a gander at 1-and-1, or most of the providers on the Personal Colocation site (and almost every other hosting provider in the world) they apportion your bandwidth in GB per month. Exactly what does this mean to people that are more familiar with buying bandwidth by the circuit? Exactly how much bandwidth is 500GB/Month? Is that equivalent to T1 internet (DS1 or E1 for you euros?) (read more…)
This March, Daylight Saving Time (DST) changes for the United States, starting the time change 4 weeks early. Congress in its infinite wisdom changed DST in the Energy Policy Act of 2005. Other countries such as Australia have followed suit. For most people, this will come as an early relief from winter doldrums, but for IT, the DST change is a major headache. After Year 2000, IT vendors were smart enough to start using 4-digit date codes, but DST changes are still hard-coded for the 1st Sunday of April and the last Sunday of October.
To accommodate the DST change, most IT systems must be patched. Otherwise, timestamps will be off, and some applications my fail to work. For instance, if you synchronize your Windows Smartphone with Microsoft Exchange, and you want your calendar reminders to work, plan on applying patches or fixes to Windows XP, Windows 2003, Exchange 2003 & Windows Mobile. Otherwise, you may be late for that all-important TPS meeting. (read more…)
I recently was challenged with the task of determining if any rogue access points existed on a large network, spanning multiple locations. The concern was that local staff would go down to CompUSA or Office Depot and buy APs to provide “convenience,” and IT would have no way of knowing. It was not practical to go visit each site, and we could not rely upon local staff, because they were the very people we were worried about.
We determined that the likely scenario would be that the staff plugged it in to the network and obtained an “external” IP address from our DHCP servers. The likelihood that they would have statically assigned an IP seemed slim since they would have no way to determine which IPs would fall outside the DHCP range. Also, we counted on laziness to rule the day, since it would work fine with DHCP.
I came up with the following batch script to run against our DHCP servers. It dumps all current DHCP lease holders, and then checks them for known AP MAC address prefixes.
The purpose of this paper is to detail the design of a production firewall for an e-commerce company. Companies with websites and other public facing services do not take into account correct security practices for their network. It is important to understand the security needs of protecting their web site and other Internet facing computer systems.
A firewall is the focal point in network and system security. This paper will look at proper firewall standards and best practices, modeled after Cisco SAFE and CERT, for using a firewall in an e-commerce network. Proper DMZ design and the physical placement of the firewall will be discussed. Also, firewall security policy rules, and how best to configure them. Besides normal firewall design, this paper will list other ways to secure the firewall itself, with proper logging and daily backups of the configuration, security audits, and disabling unneeded settings.
This paper will give network administrators a proper guide to securing a network and the firewall.
Warning: DOMDocument::loadXML(): Opening and ending tag mismatch: hr line 1 and BODY in Entity, line: 1 in /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/plugins/inlineRSS/inlineRSS.php on line 174
Warning: DOMDocument::loadXML(): Opening and ending tag mismatch: hr line 1 and HTML in Entity, line: 1 in /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/plugins/inlineRSS/inlineRSS.php on line 174
Warning: DOMDocument::loadXML(): Premature end of data in tag P line 1 in Entity, line: 2 in /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/plugins/inlineRSS/inlineRSS.php on line 174
Warning: DOMDocument::loadXML(): Premature end of data in tag BODY line 1 in Entity, line: 2 in /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/plugins/inlineRSS/inlineRSS.php on line 174
Warning: DOMDocument::loadXML(): Premature end of data in tag HTML line 1 in Entity, line: 2 in /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/plugins/inlineRSS/inlineRSS.php on line 174
Warning: XSLTProcessor::transformToXml() expects parameter 1 to be object, boolean given in /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/plugins/inlineRSS/inlineRSS.php on line 174
Horrific XSLT error - Dice returned empty - verify /homepages/5/d178659836/htdocs/edgeblog/wordpress/wp-content/in_Dice.xml is a valid XML file and check logs.