Online Retailer Expo – iPad 2 Give Away Congratulations

Published September 30th, 2011 by bsmith

As mentioned in our previous post, Anchor have spent this week at the Online Retailer Expo . While we were too busy talking to attendees to catch any of the seminars, we had a smashing time!

The width and breadth of online initiatives that we saw at the event (at other booths and through conversation) promises a bright future for Australian consumers. Personally we’ll be happy to get our online purchases come from a local address rather than having to deal with customs, however I digress.

While at the event Anchor gave away not one, but two iPad-2s!! The allure of surfing net and media from the comfort of your couch (or really, anywhere, be it bus or bed) was great as we saw just about everyone who passed stop to drop their card!

Apple iPad 2 giveaway

We had both a white and black iPad 2 up for grabs!

Choosing a winner is never an easy task, so we left it to fate and a winner was selected on Tuesday (via the blind grope/pull out card method). A big congratulations to our two lucky winners (below).

Lucky iPad winner

Fiona B, the winner of the Wednesday iPad draw

Kelvin K, the winner of the Tuesday iPad draw

A big thank you to everyone who stopped at the Anchor stand, furthermore thanks to everyone who not only had a go at our nerf guns, but refrained from shooting us in the face.

We will see you at next years Online Retailer!

0
Comments

When HA won’t play the way you want it to

Published September 8th, 2009 by oliver

In an ideal world every service would support High Availability and Load Balancing, would scale up easily and cleanly and all of us systems administrators would be paid bucketloads to play golf all day while the computers did all the hard work. To quote Dylan Moran of Black Books fame, “Don’t make me laugh…bitterly”.

I’ll cut to the chase – sometimes you have to really shoehorn technologies to do what you want. Fortunately I love doing this, and the technologies of today’s article are virtualised Windows 2008 on Xen, and Oracle XE 10g. Neither likes to play ball, for a few reasons:

  • Generally speaking, when you virtualise an OS you want to have para-virtualisation drivers enhancing the hardware support. Open Source Xen has PV drivers, but they are not signed with a legitimate certificate. Windows 2008 does not play nicely with unsigned or test-cert-signed drivers.
  • Oracle is just a messy, messy, nasty thing. Yes, paid versions undoubtedly support all manner of loadbalancing and HA options, but the free one does not.

Adding HA to Windows 2008 on Xen

The basic procedure was as follows:

  • Install the telnet server within Windows (making sure to lock it down in the firewall to only be accessible by the host machines)
  • Create a special admin account and password used for triggering a shutdown
  • Create an Expect script which logs into the VM via telnet, and issues the shutdown command
  • Create a modified version of the Heartbeat Xen resource agent which calls the expect script to shut down the VM (and wait a safe period of time) before “xm shutdown” is called. Without this, “xm shutdown” will simply power off the VM (in absence of working PV drivers).

The VM was already running on a DRBD volume between the two HA Xen servers, so I was able to just create a standard set of Heartbeat resources to control DRBD primary/secondary mode and the startup/shutdown of the HA WIndows VM. For your benefit (if you want to recreate it) here is the expect script:

#!/usr/bin/expect -f
#
# Script which "automates" shutting down a Windows VM

# Don't log telnet output and commands to stdout, and set a reasonable timeout.
log_user 0
set timeout 3

# Log in via telnet and issue commands. Fairly straightforward.
spawn -noecho /usr/bin/telnet 192.168.1.1
sleep 0.5

# login as the "shutdown" user
expect {
 -re "login: $" {send "shutdown\r"}
 timeout exit
}
sleep 0.5
expect {
 -re "password: $" {send "mysecretpassword\r"}
 timeout exit
}
sleep 0.5
expect {
 -re ">$" {send "shutdown /s /t 0\r"}
 timeout exit
}
sleep 0.1
expect {
 -re ">$" {send "exit\r"}
 timeout exit
}
exit

The rest is fairly self-explanatory if you understand Heartbeat.

Oracle XE 10g

This was more of a learning process, since usually you just install Oracle and leave it the hell alone. Not so for me.

  • Install Oracle on both nodes using (fortunately) the RPMs they provide
  • Configure Oracle on both nodes including creating the databases, using the same password for SYSDBA
  • Shutdown both instances of Oracle
  • Create the DRBD resource, and mount it on the primary node
  • On the primary node, move the contents of /usr/lib/oracle/xe/oradata and /usr/lib/oracle/xe/app/oracle/flash_recovery_area onto the mounted DRBD
  • On the secondary node, delete the aforementioned paths
  • Bind mount the oradata and flash recovery area from the mounted DRBD volume into the correct places in the directory tree.
  • Start Oracle

After I had created a Heartbeat resource group which contained the DRBD resource, the DRBD filesystem mount, the aforementioned bind mounts and the Oracle service itself I was quite pleased to see that Oracle plays quite nicely with our shoehorned HA setup. You’ll want to make sure you have a properly fixed Oracle init script though, as the supplied one is fairly bad.

After making Oracle and Windows 2008 work nicely in HA, I’m almost certain any service no matter how bad can be shoehorned in a similar way to give you decent availability even when it was n’t originally intended.

0
Comments

Wireless IP KVM mk II

Published April 28th, 2009 by oliver

If you have been following this blog for a while you might have seen my previous article on the portable, wireless IP kvm that we constructed a while back for datacentre use. This has proven to be an invaluable tool for remotely accessing machines instantly, in fact so invaluable that contention for its use frequently causes consternation. When I completed the last device, I made a list of how it could be improved in a future revision so when I decided we needed a new one, I thought I’d take care of some of the improvements I had planned.

To refresh your memory:

  • remove covers of internal components to reduce space requirements and improve cooling
  • align the wireless antennae in the middle of the case so cables from the wireless bridge are hidden
  • reuse PCB mount points to screw the boards into the kit box, or use some sort of glue
  • install a unified power supply for the wireless bridge and IPKVM

As you’ll see below, I have taken care of all of these concerns and more.

Wireless Bridge with bottom removed

Wireless Bridge with bottom removed

As soon as the wireless bridge and IPKVM hit my desk, the screwdrivers came out. I set about taking out the cases off the bridge and the IPKVM and seeing what the circuit boards were like.

Wireless bridge circuit board exposed

Wireless bridge circuit board exposed

As you can see, Linksys just use a miniPCI wireless card on the bridge and a couple of standard antenna cables. I wondered what might be under the copper shielding but I didn’t want to destroy anything too early on in the process so I had to suppress my curiosity.

IPKVM circuit board

IPKVM circuit board

The IPKVM circuit board is quite neat and tidy. A perfect candidate for removing the casing! At this point I inspected the boards to see what kind of power supply I’d need. The IPKVM takes 5v but the wireless bridge takes 12v. Jaycar had some nice small switched AC/DC power supplies which can output up to 25w at 12v. This is fine for the bridge but I’d need some sort of regulator for the IPKVM.

I started looking at voltage regulator components such as an LM7805, but most would only do up to 1A and the IPKVM is rated to 2A. It is of course possible to build a 2A regulator using two LM7805s and some supporting components but that would mean building a circuit board, finding a good circuit design and spending a reasonable amount on the components – LM7805s aren’t cheap! I decided to find an alternate solution.

5v UBEC

5v UBEC

Hobbyists frequently pack a lot of batteries in their remote control cars and planes and use tiny, lightweight voltage regulators to bring the voltage down from 14.4V to 5V which the motors require. These are easily found on Ebay for less than $10 and do the job perfectly, so I found one and pretty soon it was on my desk. Above you can see the size comparison with a standard coin.

IEC power cable

IEC power cable

After a trip to Jaycar, I had most of the remaining components, including an IEC power socket and 3-wire AC cable. With this connected to the power supply, we can easily connect the Wireless IPKVM straight to our APC power rails in the datacentre.

25W Power Supply

25W Power Supply

Here you can see the 12v 25W power supply. It is quite small due to it being a switch-mode design, and better yet has a cool little LED showing it is on. Sadly you can’t see this from outside the IPKVM.

Testing 12v

Testing 12v

It’s always good to cover all your bases when constructing like this, so I made sure to break out the old multimeter and check all the voltages. 12.2v unloaded voltage out of the PSU here is pretty good.

Cool LED

Cool LED

Note the awesome power LED on the PSU. The input/output terminals are the easy-to-use screw-down type. There also appears to be some sort of fine-tuning adjustable cap on the board which might change the output voltage but I wasn’t keen on making any changes.

Testing the UBEC

Testing the UBEC

Now it was time to test the output from the 5v regulator. Yes, right on 5.3v. I was pleasantly surprised by the glowing red LED supplied complimentary on the UBEC. The UBEC actually heats up a little bit despite being switch mode – supposedly it gets up to 92% efficiency which is great.

DC connectors

DC connectors

Voltage testing done, I prepared the 12v and 5v outputs with DC connectors suitable for the wireless bridge and IPKVM.

My neat testbench

My neat testbench

Here on my very neat testbench I have connected up the wireless bridge and IPKVM to the 12v and 5v outputs respectively. Lights are on! Everything seemed to be good at this point so I configured the bridge and IPKVM with final deployment settings, updated our documentation and started planning for building it all into a kit box.

Test fitout of the kit box

Test fitout of the kit box

Another trip to Jaycar later, I had my kit box. The form factor is a bit different to the mk I Wireless IPKVM – whereas the first incarnation was long, wide and flat, this one is a lot taller but narrower. Since we are stacking the boards and other components there will be less open space but hopefully the overall result will be neater and more compact. Above is the test placement of the PSU and IPKVM board. The IEC power connector nicely sits next to the PSU.

Fans!

Fans!

A bit of interest in the project generated around the office as it started to take shape. One coworker offered use of his dremel to cut the requisite holes in the box for connectors and another donated a couple of small 12v cooling fans to aid active cooling of the components rather than hoping passive cooling would do. This is probably a necessity, as the PSU and UBEC heat up a reasonable amount under load. I am assuming the IPKVM and Wireless bridge are no different.

Fan and power

Fan and power

I installed two fans both operating in the same direction so airflow would go through the box. It is completely sealed apart from these openings so having the fans both blowing or both sucking would be fairly disastrous. You can see that the IEC power socket sits nice and flush with the box wall. I’ve screwed it in, but also added copious amounts of hot glue :)

Starting the glue-in

Starting the glue-in

At this point I’ve got the power supply glued down, the fans in and the power connector secured. The IPKVM is glued down at the front and underneath, with a small section of cardboard to keep it leveled and some more at the back to brace it against the side of the box. This time around I crimped RJ45 connectors on a small length of Cat5 cut to measure so I didn’t have a huge amount of cable inside the box. Everything is ready for the wireless bridge!

Concealed antennae

Concealed antennae

As per my improvements list, I wanted to have the antennae concealed and this is just what I did. A bit of hot glue here and there and we have the antennae secured to the lid of the kit box, waiting for the mini-N connectors to be screwed in.

Wireless bridge installed

Wireless bridge installed

I was able to cut a few notches in the side posts of the kit box which allowed the wireless bridge to slot in nicely. I hadn’t even planned for this so it was a nice surprise. A bit more hot glue, and it is secure in place.

Blinkenlights

Blinkenlights

It would be a crime against humanity to not make use of blinkenlights wherever possible, so I drilled a few holes in the front of the box to allow the wireless bridge LEDs to poke through. Largely useless, since nobody will be watching it, but this is an important feature nonetheless.

Important warning

Important warning

Adorned with the official Blinkenlights warning, the Wireless IPKVM is now ready for use!

Finished product

Finished product

With cables

With cables

So there you have it. This project was definitely a success and there are already calls for me to rebuild the original Wireless IPKVM in a box like this one. I can’t think of any major improvements I’d like to make next time around, except perhaps for a transparent kit box with far more blinkenlights.

0
Comments