Recently in redundancy Category

I hate acronyms.

Of course they're impossible to avoid if you work in IT, but that doesn't mean I have to like them.

RAID is one of those acronyms that really wrecks my head.

Not RAID itself which means simply Redundant Array of Inexpensive Disks, but the different types of RAID array that can exist.

RAID, in case you didn't know, is a way of improving redundancy and performance in servers by using multiple disks. Of course you don't have to use multiple disks, but if you don't you will run the risk of losing data.

A few months ago someone posted a very nice simple graphic that explained the differences between the various types of RAID arrays.

Taken from: http://www.epidauros.be/raid.jpg

One of our technical staff sent me a link earlier today to a bash.org quote which sums up the potential issues with single disk servers very nicely:

sterano: Whats the difference between Raid_0 and Raid_1? Steve: In Raid_0 the zero stands for how many files you are going to get back if something goes wrong.

Moral of the story - use more than one physical disk :)

If you want to know about any service affecting maintenance, technical updates or anything else of a technical nature, we recommend that you check out our new Technical Blog.

The site is hosted outside our core network (we don't even use our own nameservers just to be 100% safe!) and is part of our backup / contingency plans for emergency situations.

While our network uptime has been and hopefully will continue to be exemplary there's no reason to be lazy. We need to make sure that we have a system in place in case there is an issue NOT after the issue arises.

You can subscribe to the site's RSS feed OR to the email alerts.

Your choice :)

You can sign up for the email alerts by filling out the form below:

Journalists call from time to time asking me to talk about various internet related topics. Most of the time the publications or shows are "general interest", so you can only talk about very general things.

Last night, however, was quite different, as I was one of the guests on "Domain Masters" which is broadcast and streamed weekly at 7pm EST (11pm in Ireland, midnight CET)

The show's host last night was my good friend Jothan Frakes who is one of the domain name industry's gurus.

Although I was very nervous (which probably showed!) we had a nice chat about Blacknight, domains and the internet industry.

If anyone wants to hear the show there should be an mp3 version available on the WebmasterRadio site at some time over the next couple of days.

UPDATE: The Mp3 from last night is now available on the site http://www.webmasterradio.fm/Internet-Marketing/Domain-Masters/Geo-Domain-Expo-and-BlackKnight.htm

UPDATE 2: Of course if I provided proper hyperlinks people might be actually able to use them!
So here you go: Show details including podcast

When: INEX LAN#1 connection being upgraded @ 23:00 on Monday 10th of March.

What: We currently have 2 x 100M connections to INEX. Our LAN#1 connection carriers a lot of our INEX traffic and as such we're upgrading it to 1000M to prevent it being a bottle neck for traffic originated in Ireland. This is a simple software configuration change for the port speed on one of our routers and requires INEX operations staff to do the same on their end.

There'll be a brief hit as all our INEX peerings on LAN#1 go down and traffic re-routes over LAN#2 and transit. This should only be temporary and peerings should re-establish automatically after a few minutes.

Summary: @ 23:00 on March 10th we're upgrading our primary Connection to INEX to 1000M. Traffic reaching us via INEX peerings on LAN#1 should be re-routed via LAN#2 and transit with minimal downtime being incurred, just the time it takes for BGP to reconverge.

Update: 23:25 March 10th 2008

This upgrade went ahead without a hitch. We're now running at GE @ INEX on Lan#1. We'll upgrade Lan#2 later in the year as necessary.

When: Monday 10th of March @ 22:00 hours

What: Firstly we've recently lit our own protected wavelength between DEG and InterXion. It has been in place and in testing for a few weeks now. We need to test the failover on both the long and short legs of this new connectivity and also check the failover to the backup layer 2 paths in the event of both the short and long legs getting damaged at the same time.

We don't expect any downtime during this testing as our layer 2 network normally fails over within a few milliseconds.

Secondly we're moving the InterXion firewalls to the new Distribution routers in this location. This change should take 30 seconds or so to propagate within our network as it's a logical Layer 3 change.

This will mean the firewalled network in DEG and InterXion will be seperated from each other and traffic originating and destined for each data centre doesn't need to traverse our metro network.

For complete testing we'll allocate 2 hours to perform these tests. We don't envisage anything more than a few 10-30 seconds hits on metro traffic (so won't affect everyone) and it will only cause slow loading times for some websites and not others.

Summary: Works begin @ 22:00 hours on Monday 10th and end at midnight on Monday 10th. There should only be a few short hits on our metro links as they failover while we simulate fibre cuts, switch failures, port failures etc.

Update: 23:58 March 10th:

These tests have been completed. The inter DC links have been tested in several scenarios are we're happy it's quite resilient now. We also moved the InterXion firewalls to a new distribution router pair in InterXion from the DEG routers. This took a little longer than expected, around 3 minutes and 40 seconds or so, slight OSPF glitch in the config which took a minute or two to find. All went to plan except that firewall move in the initial stages.

Overview:

On 10:04am on 4/2/2008 an ethernet card failed in a device on one of our metro-e providers Layer 2 connectivity device in DEG. Immediately (within 50ms) our kit failed over to our backup route into DEG. There was no service disruption during this window due to our resilient network design. At 12:00 the card was replaced and this link came back up and we flipped our traffic back over to our primary link. Again service was unaffected.

We received the RFO from our metro-e provider yesterday afternoon that basically said what I've described above. A card failed and it was replaced within 2 hours.