Friday, October 23, 2009

A New Way to look at Networking

I've started watching a google talk by Van Jacobson on networking. It's two years old ... I need to start watching more google talks. Most of the ones I've seen are amazing. This is no exception.

Google Tech Talks August 30, 2006 Van Jacobson is a Research Fellow at PARC. Prior to that he was Chief Scientist and co-founder of Packet Design. Prior to that he was Chief Scientist at Cisco. Prior to that he was head of the Network Research group at Lawrence Berkeley National Laboratory. He's been studying networking since 1969. He still hopes that someday something will start to make sense. ABSTRACT Today's research community congratulates itself for the success of the internet and passionately argues whether circuits or datagrams are the One True Way. Meanwhile the list of unsolved problems grows. Security, mobility, ubiquitous computing, wireless, autonomous sensors, content distribution, digital divide, third world infrastructure, etc., are all poorly served by what's available from either the research community or the marketplace. I'll use various strained analogies and contrived examples to argue that network research is moribund because the only thing it knows how to do is fill in the details of a conversation between two applications. Today as in the 60s problems go unsolved due to our tunnel vision and not because of their intrinsic difficulty. And now, like then, simply changing our point of view may make many hard things easy.

Working Under the Influence

Let me just say this first: I like coffee.

I assumed that every other system administrator drank coffee/caffeinated beverages as well. Caffeine has become part of the larger (computer) subculture; Jolt, Mountain Dew, and Coffee, all have come to represent the official drinks of Hackers, Programmers, and Engineers. But based on a question I posted on serverfault, the water-drinkers are more numerous than I thought.

Similar findings are found on the blog The Quantified Self, where Robin Barooah conducted a personal experiment investigating concentration and caffeine. R0bin found that concentration and caffeine may be mutually exclusive. While none of these results are conclusive, they certainly are provocative.

Caffeine is often used to cover other deficiencies: lack of sleep, motivation, and boredom. During these times concentration is sure to be a problem as well. Caffeinating these problems is only addressing the symptoms and not the root causes.

I may try my own experiment soon; cutting off coffee, and moving to water. Of course, every once in a while, I'll cheat.

Monday, October 12, 2009

SQL Fuzzing with Performance Data

I've been asked to test the replication and fail-over procedures at work. Since we have several large databases on as many servers, this is an important part of our Disaster Recovery program.

The question is: How can I create a realistic fail-over of a database without disrupting production systems?

Three different issues need to be addressed:

  1. Does the current fail-over mechanism work?
  2. What happens to current connections during the fail-over?
  3. What happens to the data during fail-over?

Answering these questions means that I will need to simulate at least two live database servers, and their connections to multiple clients.

Deploying two new database servers is a trivial process (thanks to VMware). But creating multiple connections, and finding a data source to log is more complicated.

I suggest taking performance monitoring data (cpu, memory, and disk usage) from another system, and logging it to a database. This will simulate a live database without mirroring a production system, or reinventing the wheel for a simple test.

Because performance monitoring data is always changing, it is very easy to generate large, diverse databases from a very simple data source. You will also have several clients that can be interrupted mid-update without too much trouble.

This fuzzzing can also be used in a classroom environment. Giving students an opportunity to manage a "live" database system. Traffic loads, and stress testing can be simulated by decreasing the update interval.

Happy fuzzing.