VelociPeek

Song of The Day: Hyperpower! - Artist: NIN

So you want to add custom modules to Apache on OS X. Well, you’ve come to the right place. I just recently decided to do this and wrote a few notes on the experience. It still surprises me how tough it can be to come across a fairly simple write-up on something like this without touching at least a couple of manuals or READMEs. Hopefully, someone will find this useful. As an added benefit, although the entry is focused upon OS X, the instructions should work on most Unix and Unix-variant platforms.

Currently, OS X 10.4.9 comes stock with Apache httpd 1.3.33, so you’ll need the 1.3 source code to start. That may be downloaded here. The last I checked the build number of the released version of Apache 1.3 is 1.3.37. In the future I plan to document any Apache 2.0 vagaries during a custom module setup; however, today the entry addresses 1.3.x solely.

<Note>
Be careful to not overwrite your existing Apache /usr/sbin/httpd or shared modules. If you do not want to affect the existing installation, then back it up and/or use the appropriate configuration commands during Apache compilation. For example,

</Note>

To get things moving quickly, I first decided to get mod_example.so working, which comes with the Apache distribution. I did this by adding the following to the file [src base]/src/Configuration:

To build the module just invoke make, or if the configuration options are not preset:

Now, if you want to run the module, you may add the mod_example functions to Apache’s configuration by editing the httpd.conf with the following:

To ensure success hit the URL (e.g., http://localhost/example-info) and something like the following should display: mod_example output.

<Note>
If Apache isn’t set up, then you can build most of the modules as shared objects with the following configuration options as a part of the build directives to configure:

</Note>

With a lot of the build environment issues behind us, we are ready to start creating our own module. Probably the best way to get started is by copying the mod_example code into a new directory and to configure the build settings. For this entry I have decided to use the name mod_cpeek for the Apache module. Here are the commands under the Apache source directory that I used:

The sed commands allow us to use a different module name and handler from the mod_example ones. These changes help to avoid name collision when exporting the cpeek module and help to identify the cpeek handler in configurations. We may also add the custom module to the build path of Apache 1.3 by editing the [src base]/src/Configuration.tmpl and adding the following:

Afterwards, we need to run [src base]/src/Configure to update the configuration and make files.

Once that is complete, we should be able to copy [src base]/src/modules/cpeek/mod_cpeek.so to our libexec directory of shared modules for Apache. If there is a problem at this stage it may be useful to run the following again to clear any misconfigurations:

Now, the custom shared module should be in the same shared module directory of the Apache installation (e.g., /usr/local/apache/libexec for Apache directory structure and layouts or under /usr/libexec/httpd for the default OS X location.

Add the following to the httpd.conf:

If everything is compiled and configured correctly the new URL “/cpeek-info” should display the same results as the /example-info using the cpeek-handler and namespace.

Okay. That concludes the fun for today. Next time we’ll take the Apache API for a whirl.

Tags: Eric O’Laughlen, Apache Custom Modules

Song of The Day: Available - Artist: Moving Units

So it’s been a while since I’ve posted. Don’t mean to let my blog slip, but I’ve been pretty busy lately. For one I took a graduate class in fault tolerant computing that started in January. That class has been awesome; however, now that I also started a new job with Corporate Technology Partners, Inc. I’ve had little time for anything else :).

I’m sure there are some that would be interested in knowing what I’m doing at CT Partners, and possibly how that all relates to VelociPeek.com LLC. Rest assured, I’ll make some sense of it all in future posts. For now I’d like to delve a little into reliability. And I don’t mean job reliability, silly! :) Today, I mean computer system reliability.

What’s interesting to me is that there used to be debates about system’s reliability and availability within AOL concerning certain, unnamed, systems (um, those systems will remain anonymous). It’s amusing, somewhat, to ponder this all now. I mean most technical folks understood–mostly OPS folks–the relation of: (Availability = MTTF/(MTTF+MTTR)); however, I wonder how many truly appreciated the field of study and theory behind it all. I appreciated the field and usefulness, but my current class has given me an opportunity to delve a little deeper into the field of research. Because of my experience and current study, I thought I’d share a few thoughts about it now.

So what is reliability?

Reliability is the probability that a particular system will be running up to a given time. Given some failure rate (FR or λ), a unit number, and a mission time (T), we can define reliability (R) as: R(T) = e^[-(λ * T)]. e = the base of the natural log = ~2.7182.

So isn’t that availability?

Well, not exactly. Availability, or what we’ll call operational availability (Ao), is the probability that a particular system will be operational at a particular time. Many people use these interchangeably, but technically and mathematically, they’re different. Reliability is about probability of failure within a system; whereas, availability is about the probability of overall operation. Mathematically, Ao = MTTF/(MTTF+MTTR), or the proportion of the mean-time to failure to the sum of the mean-time to failure and the mean-time to recovery. There are varying definitions of availability (e.g., does it include planned maintenance, etc.); however, this formula will suffice for most discussions. Regarding MTTF within Ao, some refer to MTTF as reliability; however, that doesn’t fully describe it.

Perhaps an example is best to illustrate.

FR provides the fraction of units that failed within a given time period. For example, let’s say out of 2 computer chips 1 failed in 10 hours. This would yield an FR = { 1 chip failed/(2 chips * 10 hours) } = 1/20 or .05/hr. The inverse of the FR is the MTTF (-(λ) or (1/λ)), MTTF = 1/(.05/hr) or 20hrs.

Given this metric, what is the reliability of this 2 chip system?

Well, you can plug things in: R(T), T = 20, λ = .05, then R(20) = e^[-(.05)*20] = ~36% reliable in 20 hours. So far FR = .05 and MTTF = 20 hrs. If we pick an average recoverability of say 1 hour, we have Ao = 20/(20+1) = 95%. If our failure rate increases (e.g., FR = { 1 chip failed / (2 chips * 1 hour) } = .5) then our reliability and availability go down: .004% for a mission T=20, and Ao = 66%, respectively. Hopefully, that helps to show the relationship between the terms.

So how does this all relate to those previous debates?

Well, ignoring all those other complications regarding the theory of reliability and availability for a moment, one can derive a correlation between failure rate, cost per failure, and cost of a reliable and available system. For a business this type of understanding can help improve communication (e.g., expectations) and total cost of ownership (TCO). Hmm…that does appear useful :).

Well, that’s enough for this entry. Since there is a lot more that could be written, I may have to revisit this later for series and parallel configurations. Both topics are interesting and useful. For a good reference on some of this, check out START Volume 11, Number 5.

600) )4j

Tags: Eric O’Laughlen, Reliability