Since I got my Dell Vostro 1440, I felt that it wasn't quite as responsive as it should have been. Yesterday I spent a little time trying to figure out why that might be. (A little time -- like all morning.) I stumbled across what seemed like good instructions on troubleshooting Linux video. At the start of all the instructions was a warning to make sure the user was in the video group. If not, the user's desktop wouldn't be able to use the graphics hardware.
Well I checked my groups, and sure enough I wasn't in the video group. I added myself to the video group, and after logging out and in, and a day of use, I'm confident in saying that the desktop is much more responsive.
More Googling turned up a useful command: 'glxinfo | grep "direct rendering"'. It will tell you "yes" if you're going straight to the graphics hardware.
Thursday, 16 February, 2012
Friday, 27 January, 2012
Installing Ruby on Rails on Ubuntu 11.10
[I've made an important change to this post -- steps 3 and 4 below are new. Apologies to anyone I've lead astray.]
I'm back to playing with Rails a bit. NetBeans for Ruby is gone, so I'm going to do things the macho Rails way and just develop with an editor and a bunch of terminal windows. (One of my open source rules is "do whatever everyone else is doing." Trying to use an IDE with Rails was always a violation of that rule.)
rvm is a great idea. I found it really helpful to read about named gemsets early on. I had to install rvm, then install rails and a few other packages.
Now create an application to test:
Browse to localhost:3000 and you should see the Rails default page.
I'm back to playing with Rails a bit. NetBeans for Ruby is gone, so I'm going to do things the macho Rails way and just develop with an editor and a bunch of terminal windows. (One of my open source rules is "do whatever everyone else is doing." Trying to use an IDE with Rails was always a violation of that rule.)
rvm is a great idea. I found it really helpful to read about named gemsets early on. I had to install rvm, then install rails and a few other packages.
- Install the Ruby Version Manager (rvm) from these instructions
- Put this line at the end of your .bashrc: "[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function"
- Run "rvm requirements" in a terminal window
- Install all the packages the output of "rvm requirements" tells you to install (apt-get install...). You must do this before you start installing any rubies with rvm. If you don't, you may have all sorts of problems crop up later, like weird messages from irb ("Readline was unable to be required, if you need completion or history install readline then reinstall the ruby.")
- Do the following in a terminal window:
rvm 1.9.3 rvm --default 1.9.3 gem install rails sudo apt-get install sqlite sudo apt-get install libsqlite3-dev sudo apt-get install nodejs Now create an application to test:
rails new testapp cd testapp rails server Browse to localhost:3000 and you should see the Rails default page.
Sunday, 22 January, 2012
Know What You're Building
"Know what you're building" seems like an obvious thing to say, but I don't think we do it that well in IT. For my recent data centre relocation project, we applied that principle successfully to a couple of areas. The network lead wrote up exactly what he was building, and the storage lead listed out every device he needed. But we never did a complete "final state" description of the new data centre.
It all worked pretty well, although we needed a number of meetings during the design phase of our new data centre -- laying out the racks, non-rack equipment, power, cabling for the networks. I think we needed to have a lot of meetings because there isn't a commonly accepted way to draw a plan of a data centre that covers the requirements of all the people in the room.
I'm running into the issue again in a smaller way now that we're designing the new central communication room for the equipment that used to be in the old data centre, but needs to remain behind for local operations (mostly the network gear to service a large office building).
Just as a refresher, here are all the people you need to involve:
Add to all that the fact that the technology in a data centre is constantly changing, at least in terms of the number and type of servers in the room. Also, the requirements and constraints tend to be circular: For example, the number of network ports on a server affects the amount of network gear you need, which affects how many servers you can have (either through port capacity or rack space), which affects how much power and cooling you need but also how many network ports you need.
You also have to worry about other details than can seriously derail an otherwise great plan. For example, when running fibre, you need to make sure it's the right kind of fibre and that it has the right connectors. Power cables in a data centre can be varied, so again you need to make sure that the power distribution units (PDUs) in the racks can be connected to your servers.
With all this, it can be hard for people to come to an agreement on what to build. We don't have well-established ways of describing what's going to be built in a way that everyone understands. There's software to help do this, but it tends to be unreasonably expensive for a medium-sized enterprise.
Regardless of how hard or expensive it is, there's a lot of value in figuring out what you're going to build, before you built it. We were successful using Excel and Word to describe what to build, and drawings of floor plans. We had to be extremely careful about versions and keeping the different documents in sync. In the end, happily it all worked out.
It all worked pretty well, although we needed a number of meetings during the design phase of our new data centre -- laying out the racks, non-rack equipment, power, cabling for the networks. I think we needed to have a lot of meetings because there isn't a commonly accepted way to draw a plan of a data centre that covers the requirements of all the people in the room.
I'm running into the issue again in a smaller way now that we're designing the new central communication room for the equipment that used to be in the old data centre, but needs to remain behind for local operations (mostly the network gear to service a large office building).
Just as a refresher, here are all the people you need to involve:
- The server team(s) know the physical dimensions of the servers, their weight, how many network ports they have and how they need to be configured, whether they need SAN-attached storage, backup requirements, how much power and cooling the server needs
- The network team(s) know the network devices, which have most of the same requirements as servers, the approach for connecting, which defines the need for cables and patch panels, and the cabling, which may affect weight of cable trays or floor loading
- The storage team(s) know the switching devices, which have most of the same requirements as the network devices
- The electrical engineer or consultant needs to know all the power requirements and placement of all the equipment
- The mechanical engineer or consultant needs to know the cooling requirements and placement of all the equipment
- The structural engineer or consultant needs to know the weight and placement of all the equipment
- The trades who actually build it all need to know exactly what they're building
- There's likely some other poor person, maybe a building architect, who has to pull this all together
Add to all that the fact that the technology in a data centre is constantly changing, at least in terms of the number and type of servers in the room. Also, the requirements and constraints tend to be circular: For example, the number of network ports on a server affects the amount of network gear you need, which affects how many servers you can have (either through port capacity or rack space), which affects how much power and cooling you need but also how many network ports you need.
You also have to worry about other details than can seriously derail an otherwise great plan. For example, when running fibre, you need to make sure it's the right kind of fibre and that it has the right connectors. Power cables in a data centre can be varied, so again you need to make sure that the power distribution units (PDUs) in the racks can be connected to your servers.
With all this, it can be hard for people to come to an agreement on what to build. We don't have well-established ways of describing what's going to be built in a way that everyone understands. There's software to help do this, but it tends to be unreasonably expensive for a medium-sized enterprise.
Regardless of how hard or expensive it is, there's a lot of value in figuring out what you're going to build, before you built it. We were successful using Excel and Word to describe what to build, and drawings of floor plans. We had to be extremely careful about versions and keeping the different documents in sync. In the end, happily it all worked out.
Friday, 30 December, 2011
Manual Two-Sided Printing
In my home office, I have a multi-function printer that does pretty much everything I typically need, except printing two sides. Here's how I get two-sided printing when I need it.
The printer is an HP CM1312nfi. It prints on the side of the paper facing up in the paper tray. The "far end" of the paper in the paper tray is the top of the page.
I print the even-numbered pages first. These are the "back side" or "left pages".
Print in reverse order.
I take the paper from the output tray, and turn it so that the blank side is up, and the top goes into the far side of the paper tray.
Then I print the odd-numbered pages. These are the "right side pages".
Print in forward order.
This only works for one copy at a time if I have an odd number of pages in the document. That's because you need one extra page when you print the second time to get the odd number of pages.
The screen shots are LibreOffice 3.4.4.
The printer is an HP CM1312nfi. It prints on the side of the paper facing up in the paper tray. The "far end" of the paper in the paper tray is the top of the page.
I print the even-numbered pages first. These are the "back side" or "left pages".
Print in reverse order.
I take the paper from the output tray, and turn it so that the blank side is up, and the top goes into the far side of the paper tray.
Then I print the odd-numbered pages. These are the "right side pages".
Print in forward order.
This only works for one copy at a time if I have an odd number of pages in the document. That's because you need one extra page when you print the second time to get the odd number of pages.
The screen shots are LibreOffice 3.4.4.
Saturday, 10 December, 2011
Relocating Data Centres in Waves
I've never had to relocate a data centre in one big bang. You hear stories about organizations that shut down all the computers at 5:00 PM, unplug them, move them, and have them up by 8:00 AM the next morning, but I've never done that.
The big bang approach may still be necessary sometimes, but you can mitigate a lot of risk by taking a staged approach, moving a few systems at a time.
Conventional wisdom on the staged data centre relocation is to move simpler systems, and test and development systems, first. This lets you tune your relocation processes and, particularly if you're moving into a brand new data centre, work the kinks out of the new data centre.
It sounds great in theory. In practice, we ran into a few wrinkles.
I'd say the root source of the wrinkles traces back to our environment: We had a lot of applications integrated through various tools, and a large J2EE platform running a lot of custom applications. Also, even though we had some months to do the relocation in waves, we didn't have an infinite amount of time. On top of that, business cycles meant that some systems had to be moved at certain times within the overall relocation period.
The net result is that we ended up moving some of the most complicated systems first. At least we were only moving the development and test environments. Even so, it turned out to be quite a challenge. We were slammed with a large workload when people were just learning the processes for shipping and installing equipment in the new data centre. The team pulled it off quite well, but it certainly increased the stress level.
I don't think there's much you can do about this. If your time lines force you to move complicated systems first, so be it. The lesson I take away is to identify early in planning if I have to move any complicated environments. On this project, I heard people right from the start talking about certain environments, and they turned out to be the challenging ones. We focused on them early, and everything worked out well.
The big bang approach may still be necessary sometimes, but you can mitigate a lot of risk by taking a staged approach, moving a few systems at a time.
Conventional wisdom on the staged data centre relocation is to move simpler systems, and test and development systems, first. This lets you tune your relocation processes and, particularly if you're moving into a brand new data centre, work the kinks out of the new data centre.
It sounds great in theory. In practice, we ran into a few wrinkles.
I'd say the root source of the wrinkles traces back to our environment: We had a lot of applications integrated through various tools, and a large J2EE platform running a lot of custom applications. Also, even though we had some months to do the relocation in waves, we didn't have an infinite amount of time. On top of that, business cycles meant that some systems had to be moved at certain times within the overall relocation period.
The net result is that we ended up moving some of the most complicated systems first. At least we were only moving the development and test environments. Even so, it turned out to be quite a challenge. We were slammed with a large workload when people were just learning the processes for shipping and installing equipment in the new data centre. The team pulled it off quite well, but it certainly increased the stress level.
I don't think there's much you can do about this. If your time lines force you to move complicated systems first, so be it. The lesson I take away is to identify early in planning if I have to move any complicated environments. On this project, I heard people right from the start talking about certain environments, and they turned out to be the challenging ones. We focused on them early, and everything worked out well.
Karma and Data Centre Relocations
We're pretty much done the current project: relocation of 600 servers to a new data centre 400 kms from the old one. By accident more than by design we left the move of most of the significant Windows file shares to the last month of the relocation period.
Windows file shares are known to be a potential performance issue when you move your data centre away from a group of users who are used to having the file shares close to them. We're no exception: A few applications have been pulled back to the old data centre temporarily while we try to find a solution to the performance issues, and we have complaints from people using some desktop tools that don't work nicely with latency.
The luck part is that we've developed lots of good karma by making the rest of the relocation go well. Now that we have issues, people are quite tolerant of the situation and are at least willing to let us try to fix the problems. I won't say they're all happy that we've slowed their work, but at least we don't have anyone screaming at us.
I'd go so far as to say this should be a rule: All other things equal, move file shares near the end of a relocation project.
Windows file shares are known to be a potential performance issue when you move your data centre away from a group of users who are used to having the file shares close to them. We're no exception: A few applications have been pulled back to the old data centre temporarily while we try to find a solution to the performance issues, and we have complaints from people using some desktop tools that don't work nicely with latency.
The luck part is that we've developed lots of good karma by making the rest of the relocation go well. Now that we have issues, people are quite tolerant of the situation and are at least willing to let us try to fix the problems. I won't say they're all happy that we've slowed their work, but at least we don't have anyone screaming at us.
I'd go so far as to say this should be a rule: All other things equal, move file shares near the end of a relocation project.
Sunday, 27 November, 2011
The Java Gotcha for Data Centre Relocations
Way back in time, someone thought it would be a good idea for the Java run-time to cache DNS look-ups itself. Once it has an IP address for a name, it doesn't look up the name again for the duration of the Java run-time process.
Fast forward a decade, and the Java run-time is the foundation of many web sites. It sits there running, and caches DNS lookups as long as the web site is up.
On my current project, we're changing the IP address of every device we move, which is typical for a data centre relocation. We have a number of Java-based platforms, and they're well integrated (read interconnected) with the rest of our environment, and we're finding we have to take an outage to restart the Jave-based platforms far too often.
In hindsight, it would have been far simpler to change the Java property to disable DNS caching. Run this way for a while in the old environment to be sure there were no issues (highly unlikely, but better safe than sorry). Then you can start moving and changing IPs of other devices knowing your Java-based applications will automatically pick up the changes you make in DNS.
In case the link above goes stale, the four properties you want to look at are:
Fast forward a decade, and the Java run-time is the foundation of many web sites. It sits there running, and caches DNS lookups as long as the web site is up.
On my current project, we're changing the IP address of every device we move, which is typical for a data centre relocation. We have a number of Java-based platforms, and they're well integrated (read interconnected) with the rest of our environment, and we're finding we have to take an outage to restart the Jave-based platforms far too often.
In hindsight, it would have been far simpler to change the Java property to disable DNS caching. Run this way for a while in the old environment to be sure there were no issues (highly unlikely, but better safe than sorry). Then you can start moving and changing IPs of other devices knowing your Java-based applications will automatically pick up the changes you make in DNS.
In case the link above goes stale, the four properties you want to look at are:
networkaddress.cache.ttl networkaddress.cache.negative.ttl sun.net.inetaddr.ttl sun.net.inetaddr.negative.ttlLook them up in your Java documentation a decide which caching option works best for you. (Normally I'd say how to set the parameters, but I've never done Java and I fear I'd say something wrong.)
Subscribe to:
Posts (Atom)