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.

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.

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.