Posts Tagged ‘Hardware’

My Hard Drive Is Bigger Than Yours

Over the last (almost) decade of working at the same company I have been amazed by the ever growing need for storage solutions. We have moved over time from a mixed Windows 95/98/ME environment to a homogeneous Windows 7 installation base. Where we were long ago running Office 97 we are now running Office 2010. During this time the file sizes produced by these software packages has increased dramatically. We are storing images of entire hard drive installations now where we used to rebuild from disc (cd-rom and floppies). Throw in redundant copies of critical information, along with the fact that no one ever deletes anything, and our storage requirements were growing at an alarming rate. Eventually I needed to make a change.

When I decided that it was time to take action I didn’t have any single device that could hold all of our short and long term storage needs. I also didn’t have any portable devices that could move this data around without breaking it up into small pieces first. This was becoming quite a problem. I needed to find a solid network storage device that was robust, redundant, easy to implement and relatively affordable.

One of the barriers to working in a smaller shop is always budget. There was a long list of storage devices that we simply couldn’t afford. Since I had already been using two of the original Drobo (Data Robotics) devices I decided to see what higher end options were available. I was initially impressed by the DroboElite. This device offered many of the features that we were looking for in a storage device. It was compatible with our virtual servers as well as offering a great deal of network storage. With the dual NIC (network interface card) configuration I could easily dual purpose the unit. I decided to pull the trigger. Once the new device arrived I quickly took it out of the box and started working with it. I made a few bad assumptions during the initial setup due to my previous experience with the original Drobo devices. The DroboElite is almost nothing like its predecessors. Here are a few key lessons learned:

  • You have to connect the DroboElite directly to your computer using the USB cable for the initial setup.
  • Once you have the desired volumes set up you can then access it via the Drobo Dashboard over the local area network.
  • You cannot format the volumes while locally connected. You have to format the volumes over the network after the initial setup is complete.
  • This device doesn’t work in Linux. Period full stop. I lost a day and half trying to get it to work. You have been warned.
  • The only really good way to set up these larger volumes is to format them in NTFS. EXT3/4 won’t work. You have been warned (again).
  • Only ONE computer on your network can access each volume at one time. This one took me some time to work out.
  • You really should enable a CHAP password on any volume exposed to your local area network. One computer can lock out the volume so that no one else can access it. You might not know which computer that is. You might spend days trying to figure out how to regain access to your data before you finally think to enable a CHAP password. You have been warned (one last time).
Now that we have the ground work laid out let’s take a look at the setup:

All drives are recognized and working!

At this point I have initialized the Drobo, installed all eight hard drives (2 TB, 7200 RPM) and moved it to the local area network (LAN). The primary network interface card (NIC) has been configured with a static IP address and is accessible from all the devices on my network.

Now we need to set up the individual volumes:

Volume Setup Screen

We are sharing this storage device between our regular LAN and a virtual storage network. Before this device arrived I was running virtual machines locally on their physical hosts. This was risky since a hardware failure could potentially take down multiple virtual servers. With the arrival of the new Drobo I will finally be able to run the virtual machines on the storage device. If a physical host goes down I can quickly recover by moving the virtual machine to another physical host and starting it up again. The public facing recovery time shrinks from hours to minutes.

In the example above I have set up an 8 GB NTFS volume. This will be shared on the LAN for storage. The 2 GB volumes will be used on a separate storage network as shared storage for the physical virtual servers. All of the virtual machines will be migrated to the storage network ranked by importance.

Now that the volumes are set up it’s time to start copying data over to the Drobo!

Time to start copying files over!

One of the major differences between the original Drobo and the DroboElite is that only one computer can access a volume at a time. To work around this limitation I mounted the volume on our file server and used the domain permissions to control access.

Setting Up The Storage Network For Virtual Machines

To segment the virtual machine traffic from our normal LAN traffic I set up a second switch to manage the storage network. All of the physical host servers have at least dual NICs. One NIC from each server goes to the storage switch. The storage network runs over iSCSI instead of the standard TCP/IP protocol. This service is disabled by default in the physical host. To enable iSCSI click on Configuration – Storage Adapters.

Enable iSCSI Detection In VMWare

Once iSCSI has been enabled you can scan the network for your iSCSI device.

VMWare Can Now See Your iSCSI Volumes

Click on the Storage link to format the volumes with vmfs3.

All volumes are formatted and ready to go!

Click on the Networking link to set up the network. In the following example we are running one physical network attached to our LAN and a second attached to our storage network.

I am surprised at how many virtual machines can be run over the single gigabit ethernet connection without any apparent loss of speed. I haven’t hit a limit yet where performance is materially impacted. All in all this device is very impressive. You can really push the capabilities of this storage device on a rather tight budget. Kudos to Data Robotics for producing such a robust (and affordable) network storage device! Very impressive!

Complete Care Coverage

Great video from the NC State Office of Information Technology on the need to purchase complete care coverage on your computer equipment.  We purchase it on all of our new computers at work!

Is Sugar The Laptop Or The Operating System?

Nicholas Negroponte is at it again, giving an interview in Singapore and discussing the major failings of the OLPC project.  I was struck by one thing that he said:

Putting a crank-shaft on the XO laptop was a mistake, but the biggest mistake was not having Sugar run as an application “on a vanilla Linux laptop”, said OLPC founder and chairman Nicholas Negroponte.

“Sugar should have been an application [residing] on a normal operating system,” he told ZDNet Asia in an interview. “But what we did…was we had Sugar do the power management, we had Sugar do the wireless management–it became sort of an omelet. The Bios talked directly with Sugar, so Sugar became a bit of a mess.”

After spending several years working in IT as a career I have learned that there is at times a disconnect between the words of management and the actual inner workings of a product.  This looked funny to me so I wondered what the actual people working behind the scenes thought of this.  Turns out Sugar wasn’t as bad as advertised:

Here’s the problem: through a somewhat regrettable set of naming decisions, the name “Sugar” came to represent two entirely different things. It was the name for the new learning-oriented graphical interface that OLPC was building, but it was also the name for the entire XO operating system, one tiny part of which was Sugar the GUI, and the rest of which was mostly Fedora Linux.

Nicholas, evidently, still remains blissfully unaware of any of this. As is plain to see from his own words, what he considers to be the biggest mistake of the project has nothing to do with Sugar the GUI, and everything to do with the gross, hairy, complicated systems development work that OLPC was doing to support the XO’s special hardware features. And to be clear, I mean “short bus special”, not “shiny unicorn special”.

Let me explain something to you. For most of OLPC’s existence, we had about two guys working on Sugar the UI. They were GUI developers, with GNOME backgrounds. They were not at all the same people doing systems development work to support our hardware. No resources were taken away from systems development to do Sugar. If Sugar hadn’t happened at all, we would have still had to do all the systems work to get Linux working on the XO, and it would have still taken just as long. So if you’re looking for things to blame, Sugar is not the droid you are looking for.

In truth, the XO ships a pretty shitty operating system, and this fact has very little to do with Sugar the GUI. It has a lot to do with the choice of incompetent hardware vendors that provided half-assedly built, unsupported and unsupportable components with broken closed-source firmware blobs that OLPC could neither examine nor fix.

So we wound up with a keyboard whose keys get stuck. A dual-mode touchpad, capacitive and resistive, where one mode doesn’t work at all, and the other makes the cursor spontaneously jump around and sometimes shuts off the touchpad altogether, prompting OLPC kernel developers to beg for saner hardware in the next round. We had board engineering issues that made power management practically impossible. We had a custom display controller chip that was incomplete in some regards, and completely broken in others. We had an embedded controller that blocks keyboard events and stops machine suspend, and to which we — after a long battle — received the source, under strict NDA, only to find a jungle of nested if statements, twelve levels deep, and no code history. (The company that wrote the code doesn’t use version control, see. They put dates into code comments when they make changes, and the developers mail each other zip files with new versions.) And we had a wireless chip that is so far beyond fucked, it’s just about funny.

(Each of those words is a different link. Click them all, I dare you.)

Thinking back, there’s a hardware incident I remember particularly fondly: one of our vendors sent us a kernel driver patch which enhanced support for their component in our machine. They chose to implement the enhancement by setting up a hole which allowed any unprivileged user to take over the kernel, prompting our kernel guy to send a private e-mail to the OLPC tech team demanding that, in the future, we avoid buying hardware from companies whose programmers are, direct quote, “crack-smoking hobos”.

In the end, Nicholas’ bit of interview nonsense just doesn’t pass the smell test. Customers aren’t stupid. There’s close to a million XOs out there; if Sugar was OLPC’s biggest mistake, Windows on the XO would be selling like hotcakes. Let me remind you, then, that the number of Windows-based XOs that OLPC has sold is exactly zero.

So next time you hear Nicholas break out the egg metaphors and wave his hands about the Sugar that doomed it all, shrug and smile. Hell, If I were a meaner person, I’d ask Nicholas why it is that Windows — you know, the Windows from Microsoft, mercifully unstained with the mistake of Sugar — can’t even shut down an XO without throwing up a blue screen of death.

I honestly don’t know what to say to this.  It’s a shame that the top down management style of the OLPC project nearly killed it.  I remember sitting around with my IT buddies excited about the future of Sugar and the XO laptop.  To be honest, most of us have moved on to something else.  What a shame…

Expensive Hard Drive

15MB-Hard-Drive-1222

H/T: Hermeneutic

Follow

Get every new post delivered to your Inbox.

Join 498 other followers