MRG/AMQP Keynote at STAC Performance Summit in NYC on June 4, 2009

I'll be at the STAC Performance Summit this Thursday, June 4, in New York City.  Carl Trieloff from my team will be delivering a keynote there and discussing new developments around AMQP and MRG as well as industry changes that we see coming as a result.  He'll also be highlighting some interesting performance data and work that we're doing with STAC.

The STAC Performance Summit is free to attend for end-user firms--you can find more information and register at http://www.stacresearch.com/node/4904.

How to Upgrade a Thinkpad T60 with a Full Disk Encryption (FDE) Hard Drive and Fedora

I recently upgraded my Lenovo Thinkpad T60 with a Full Disk Encryption (FDE) hard drive, a Seagate Momentus 7200 FDE.  The Momentus 7200 FDE provides encryption directly built into the hard drive: all data written to the hard drive is automatically encrypted with a key that is generated by and stored directly in the hard drive itself and cannot be retrieved.  FDE is probably the easiest and most transparent way to protect your data in case you happen to lose or have your laptop stolen.     

I boot multiple operating systems on my laptop, and I wanted a form of encryption that was secure but would also allow me to create symbolic links between different partitions and operating systems.  So, for example, both Fedora 10 and Red Hat Enterprise Linux 5 support encrypted disks via software.  But, using a FDE hard drive allows me to ensure that the entire hard drive is encrypted, while still enabling me to access transparently the different operating system partitions from each other.

I also was running out of space on my existing hard drive and wanted a solution which would allow me to migrate all of my data from my old hard drive to my new hard drive easily.  Using FDE enables that without requiring re-installation of any software in the process.

For more information on FDE with Thinkpads, see Lenovo's FAQ.

Here's how I upgraded to FDE:

Preparation Steps

1. Backup your data in case anything goes wrong!
2. Purchase a Seagate Momentus 7200 FDE hard drive.  Make sure its capacity is at least as large as your existing hard drive
   
3. Purchase a 2.5" SATA hard disk enclosure with a USB 2.0 interface.  This should cost around $15-30 and will enable you to transfer information from your old hard drive to your new hard drive.  Amazon or your local compute store should sell a lot of these
   
4. Download Fedora and create a Fedora Live CD/USB.  You will boot into this to copy data from your old hard drive to your new hard drive

Installation and Migration Steps

1. Remove your old hard drive from your laptop.  If you have a Lenovo Thinkpad T60, you can follow Lenovo's instructions for how to do this
2. Install your new Seagate Momentus 7200 FDE hard drive into your computer
   
3. Install your old hard drive into the hard disk enclosure.  Don't plug your USB hard drive enclosure into your laptop yet
4. Insert your Fedora Live CD/USB into your laptop and boot into Fedora. 
   
5. Login into Fedora and open a terminal window.  In the terminal, type  "su -" to become the root user
6. Type "fdisk -l" and note how your new hard drive is mapped as a device.  For example, on my system, this is /dev/sda
7. Plug your the USB hard drive enclosure into your laptop.  Fedora should automatically recognize and mount your old hard drive
8. Type "fdisk -l." Both hard drives should now appear.  Note how your old hard drive is mapped as a device.  For example, on my system, it is /dev/sdb
9. Directly copy all the contents of your old hard drive to your new hard drive by executing: dd if=[your old hard drive device] of=[your new hard drive device].  For example, on my system, I did dd if=/dev/sdb of=/dev/sda.  This process will likely take several hours
10. Once your copying is done, reboot your laptop.  Make sure to remove your Fedora LiveCD/USB.  You can also unplug your USB hard drive enclosure
11. Verify that you can boot into your laptop and that your operating system(s) and data are intact on your new FDE hard drive

Final Security Steps
Now that your laptop has a FDE hard drive installed, you need to finish securing it by configuring your BIOS to require a password for accessing your hard drive:

1. Reboot your laptop and enter your BIOS settings menu.  On a T60, you can do this by hitting the Blue ThinkVantage button immediately and then entering your BIOS settings
2. Go to the security settings section and enable requiring a user password for accessing your hard drive.  Type in a new user password and make sure to remember it.  From now on, when you turn on your computer, you'll have to enter this password before you can boot into your hard drive or access data on it
3. Save your settings and reboot your laptop
4. Attach your USB hard drive enclosure and delete all your old, unsecure information from your old hard drive
   

Congratulations!  You now have a fully secure, encrypted hard drive with all your data and operating system(s) on it!

Optional: Using Your Extra Space
If your FDE hard drive is bigger than your old hard drive, you will have empty space that you can use.  You have a variety of options available to you, from creating a new partition to extending existing partitions with this space.  If you use Fedora or Red Hat Enterprise Linux, you can use the graphical tool, GParted, to help with this.

If you happen to use LVM, GParted doesn't work with LVM yet.  In that case, you can read the Red Hat Magazine article, Tips and tricks: What is the procedure to resize an LVM2 logical volume and the ext2 or ext3 filesystem?, for how to increase the size of an LVM partition.  Note that the end of the article discusses using the command, ext2online.  That command has since been replaced by resize2fs.

Corporate, Customer, and Academic Open Source Communities for Next Generation Software

I submitted a paper for the NSF's Cyberinfrastructure Software Sustainability & Reusability Workshop.  I discuss some of the innovative open source models we've used to develop Red Hat Enterprise MRG:

The NSF is looking both at models of how to build sustainable cyberinfrastructure software as well as specific software that will benefit its goals like providing communities with access to a “world class high performance computing (HPC) environment.” Red Hat Enterprise MRG, a high performance distributed computing platform which integrates Messaging, Realtime, and Grid capabilities, provides both an open source model of how academic researchers, customers, and corporations can collaborate as well as powerful software infrastructure which can help the NSF meet its next-generation cyberinfrastructure goals.

For example, I discuss the partnership we have with the University of Wisconsin around Condor for Grid scheduling:

This partnership between UW and Red Hat is adding many innovative capabilities to Condor and also expanding significantly Condor's reach from research environments to enterprises. For example, Red Hat has focused on adding many capabilities which enterprises require for deployment but which are not paramount for academia. These enhancements range from new graphical management tools to enterprise maintainability to concurrency limits on scarce resources like software licenses. Furthermore, Red Hat has also focused on advancing Condor towards utility and cloud models of computing by adding capabilities like libvirt virtualization support and Amazon EC2 integration. Many enterprises are now looking at MRG and Condor for building private clouds and moving to cloud computing.

The paper also discusses how we're feeding back developments from the enterprise into academia, how we've collaborated with customers and users around AMQP and messaging, how the technologies in MRG can help the NSF meet its software goals around sustainable HPC, and so on.

You can see the submission at the NSF's site for papers.

You can also directly download a pdf of the paper from the NSF's site: Corporate, Customer, and Academic Open Source Communities for Next Generation Software.

Software is Low Latency's Weakest Link...Unless You're Running Red Hat Enterprise MRG

There's an article in today's Wall St and Technology, Software is Low Latency's Weakest Link.  The article states:

The weakest link in the low-latency value chain is older software or poorly written code, not market data feeds, lack of ultra-fast processors or older networks, according to experts at Wall Street & Technology's Accelerating Wall Street 2009 conference.

Furthermore,

"Within the applications, we see the greatest opportunity to improve latency," said Rob Wallos, global head of market data architecture at Citi during the session The Complete Low Latency Value Chain. "Hardware can give you a generic 20 percent improvement in performance, but there is only so far you can go with hardware. "

This is certainly true in general.  We have found that even moving up to exotic hardware like infiniband only provides incremental gains in performance unless you optimize your application to take advantage of that hardware.  That's why we've been working with hardware manufacturers and optimizing Red Hat Enterprise MRG for the latest hardware as well as for Linux.


For example, MRG includes RDMA drivers to achieve extremely low latency on infiniband.  Compare the results of MRG Messaging running on infiniband with standard TCP versus with our RDMA drivers:

This chart illustrates latency using 1K messages at a sustained throughput of 50,000 messages/second using MRG Messaging.  This is for fully reliable application-level latency between three peers: a producer is sending a message through a broker to a client, and that message is acknowledged back.  So, there are four network hops in this case.  As you can see with standard TCP (the red line), the latency is nothing ground-breaking at around 1 millsecond, even though we're using infiniband.  In other words, moving the application to infiniband doesn't automatically improve latency significantly.

With our RDMA drivers , however, MRG can achieve latencies an order of magnitude better--about 70 microseconds on this same particular hardware.  And, remember, this is for 1K message sizes and 4 network hops!  So, yes, it is true that in general, low latency bottlenecks are in software.  However, we have been developing MRG to take full advantage of modern hardware and also Linux, so we've pushed the bottlenecks back to the hardware domain in many cases.

I should also note that our next release of MRG will include a cross-memory driver for co-locating our messaging broker with an application client.  This would remove one of the network links for latency and should allow us to halve our latency performance.

QCon Presentation Slides For Download

I presented Next-Generation AMQP Messaging Performance, Architectures, and Ecosystems with Red Hat Enterprise MRG last week at QCon London, along with Carl Trieloff.  The talk included a detailed use case of work we've been doing with customers to build financial trading systems and stock exchanges with MRG.  Messaging deployments don't get any higher end than this, so it's an interesting study. 

In particular, we've added capabilities in MRG like LVQ, Ring Queue, and TTL so that companies can build market caches or provide updated streaming quotes directly from the messaging broker rather than build these capabilities themselves.  We've also done a lot of work to get some pretty impressive performance (e.g. fully reliable latency across three peers in around 60 microseconds).  And, of course, we support capabilities like active/active clustering for high availability and federation for disaster recovery.

Beyond the case study, we also talked about the new ecosystems that are forming around AMQP and MRG as well as new types of messaging-oriented applications people are building now.

You can download our slides from the talk here.

QCon London

I'll be at QCon London next week.  Red Hat is sponsoring a booth, and we'll be giving two talks:

• AMQP in Action
• Next-Generation AMQP Messaging Performance, Architectures, and Ecosystems with Red Hat Enterprise MRG

We've got a good customer case study and some pretty interesting features, use cases, and performance data that we'll be presenting around messaging.  Come to our talks and stop by our booth if you're attending the show.

QPid is a Top-Level Apache Project

The Apache Software Foundation announced today that it has elevated QPid to a top-level project, based on the accomplishments it has made in developing a community and software.  We did the initial submission of QPid to Apache, so it's gratifying to see that it has come such a long way now and has developed such a large community and following--including some surprising members.

"On the heels of its recent graduation, Qpid has also reached the completion of the major Qpid M4 release. We're thrilled to have our project's growth and maturity recognized by the Apache Software Foundation," said Carl Trieloff, Chair of the Apache Qpid Project Management Committee (PMC) and Senior Consulting Software Engineer at Red Hat. "With the promotion to an Apache Top-Level Project, Qpid is recognized for outstanding development based on our vibrant, rapidly expanding community, infrastructure, and for collaborative development."

John O'Hara, Chairman of the AMQP Working Group and Executive Director at JPMorgan said, "I am delighted that the Apache Software Foundation has graduated the Qpid project. AMQP is an open infrastructure for business messaging over the Internet. Apache Qpid developers have been active participants in the AMQP Working Group working in partnership with other AMQP solution developers and end-users. The ASF's provision of Qpid as its AMQP implementation adds to the range of AMQP solutions businesses can choose from to improve their efficiency." 

Read more in the full press release from Apache.

Check out QPid's new home: http://qpid.apache.org