The Cisco ASA and PIX line of devices have three independent vulnerabilities that have been discovered and patched a few days ago. Just finished up with my own devices and nothing bad to report. Here’s a summary if you don’t wish to read the long-winded Cisco one.

1. Windows NT Domain Authentication Bypass Vulnerability.

Does not affect IPSec and SSL using external authentication VPN. Only NT domain authentication.

2. IPv6 Denial of Service Vulnerability.

Affects devices configured with IPv6 (by itself or in addition to IPv4). Does not affect devices running versions 7.0, 7.1, 8.0, or 8.1. Devices with versions 7.2(4)9 or 7.2(4)10 are affected only if IPv6 is enabled. It is disabled on all devices by default.

3. Crypto Accelerator Memory Leak Vulnerability.

Memory leak triggered by a series of packets. Only packets destined for device trigger it. The leak occurs in the initialization code of the crypto accelerator. ASA devices running version 8.0.x are vulnerable. ASA devices running versions 7.0, 7.1, 7.2 and all Cisco PIX devices are not affected.

Get more of the details and patches here.

No Comments |  Print This Post

Avg Disk Queue Length is one of the main counters in the perfmon application. Avg Disk Queue Length is an estimate of requests on the physical or logical disk that are either in service or waiting for service. The value is a product of Disk Transfers/sec (response X I/O) and Avg Disk sec/Transfer.

What does it all mean? It’s confusing for many, but there are many instances where a high Avg Disk Queue Length does not mean a bottleneck. To see whether Avg Disk Queue Length is indeed showing a true representation of your disk’s performance, you need to compare Current Disk Queue Length over an interval. Add the Current Disk Queue Length to the counters graph in perfmon.

If the Current Disk Queue Length for the previous interval matches the Current Disk Queue Length for the current interval, then indeed the Avg. Disk Queue Length can be used as a general representation of the condition of your storage system.

Say your Avg. Disk Queue Length shows a value of 4, and the Current Disk Queue Length for the current interval is 3, and the previous interval was 0. This means the number of I/O arrivals is greater than the I/O completions during the interval. This results in an incorrect value for Avg Disk Queue Length – often to the horror of System Administrators.

Suppose you have determined the value of Avg Disk Queue Length is indeed accurate and useful – how much is too much? As a general rule for hard disks, an Avg Disk Queue Length greater than 2 (per hard disk) for extended periods of time is considered undesirable. If you have a RAID system with 8 disks, you do not want an Avg Disk Queue Length greater than 16. Faster hard disks with quicker access times (and therefore I/O) will allow greater flexibility with these numbers. Avg Disk sec/read and Avg Disk sec/write should be under 10ms – over 20ms may indicate a bottleneck. If while Avg. Disk Queue Length is over 2 and % Disk Time is hovering at 60% or above, you may want to look into a possible I/O bottleneck.

Below is a perfmon graph taken on a test machine. Avg Disk Queue Length reaches 36!! on a 2 disk RAID1 configuration.

Using Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) we are able to see which applications have the highest I/O reads and writes. The following screenshot shows over 9 million I/O reads and 260 000 I/O writes in a little over 4 hours uptime for a DBServer application.

Using another program called FileMon (http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx) we are able to see each program being accessed on the machine in real-time. The small screenshot shows a section of DBServer operations all within the same second. As it turns out, there were well over 300 instances during a one-second interval, correlating to the spike that sent the Avg Disk Queue Length to 36.

This particular situation was a stress test comprised of 12 users performing typical operations at the same time on a networked database server. Obviously a 2 disk RAID1 system (10K SAS) was not up to the task.

4 Comments |  Print This Post

One of the challenges with a traditional SATA or SAS hard disk based server is data manipulation.

Small databases are able to run entirely in memory, while large databases need to be stored on disk and pulled into memory when needed. One of the challenges with database servers is having a storage subsystem that can handle the raw throughput and read/write IOPS required to manipulate gigabytes or even terabytes worth of data.

As you may have seen in my benchmarks with the Dell MD1000 DAS with 14 – 15k SAS drives, the throughput is pretty good (500MB/s in a RAID 10 array) but the read and write IOPS just aren’t there yet. Hard disk access times increase with more complex RAID arrays – which is the exact opposite of what we want in a quick and powerful storage system.

SSDs are considerably more expensive than a similarly-sized SAS drive. The SSDs have IOPS that are 8-14 times that of an SAS drive. The new line of Intel SSDs (X25-E) have read IOPS in the range of 30, 000 and write IOPS in the 3000 range. If you are working with small (4K) reads and writes in a database system, you can replace 8 SAS drives with 1 SSD and achieve similar performance.

Databases with large queries will rely more heavily on the raw throughput numbers of a hard disk to measure performance. In this area SSDs still outperform SAS drives 3-to-1. I’ve worked with many companies that require reports and data collaboration that run into the gigabytes per query. It takes several minutes for some queries to be performed, something that can be drastically reduced with an SSD subsystem.

Not all large databases have large data requirements. Some large databases have mostly ‘small’ queries that move small amounts of data. Likewise, some small databases move large amounts of data with very few queries.

When sizing a disk and memory system for a database server, you must take into consideration the type of data to be stored, the main purpose of the data (for storage archive or retrieval), and the number of queries/users.

SSDs are still too expensive for most databases that have large data speed requirements. Although SSDs outperform the SAS disks 3-to-1 or slightly more in MB/s, the cost for a reliable setup is still running about 5-to-1 or more.

It is a different story when sizing a system for a web server, forum or search archive (or a similar high-use, small data transfer) database. With systems that have a large number of users pulling small data blocks, an SSD can perform read IOPS way beyond that of an SAS drive. A typical LAMP server running a vBulletin forum can handle more than 30 times the traffic of an SAS drive.

How nimble is your data? With the new crop of SSDs, ease of data manipulation will increase substantially. It is far too taxing on database servers to run various “what-if” scenarios. It simply takes too long to perform. MySQL, Oracle, Sybase, MSSQL all run well until they run out of memory and need to page the hard disks. This is where SSDs will be leveraged. Large enterprises will be able to manipulate their data faster and more effectively without their servers grinding to a halt.

No Comments |  Print This Post

With a fresh install of Windows 2003 on the Intel SE7221BA1-E server board, no default graphics driver is loaded. This causes an “out of range” message to appear on most monitors after the LOAD screen finishes, when the logon screen is supposed to appear.

The solution is to press F8 when the server loads up and either enter SAFE MODE or VGA MODE.

Then install the Intel Chipset drivers found here and the Intel Graphics drivers found here.

4 Comments |  Print This Post

Ridata announced three new SSDs today (Ultra-S Plus Series) in 32GB, 64GB and 128GB models.

The new drives utilize the multi-level cell technology – resulting in lower cost, but also slower speed. The drives will have a nominal read speed of 128MB/s and a write speed of 80MB/s. The drives will retail for $170, $295 and $538 US respectively.

Although choosing these drives for speed is ultimately a poor decision due to the availability of inexpensive SATA/SAS RAID configurations, there is simply no denying the amazing access times – 0! ms. These SSDs are fantastic for IO performance. They are well suited for database servers that are small in size but handle above average volumes of requests.

http://www.ritekusa.com/pressrelease.asp?pressreleases_id=54

No Comments |  Print This Post