Understand the processor and memory-sizing considerations when implementing Virtual SCSI .
When you are designing and implementing a Virtual SCSI application environment, consider the following sizing issues:
The processor impacts of using virtual I/O on the client are insignificant. The processor cycles run on the client to perform a Virtual SCSI I/O operation are comparable to that of a locally attached I/O device. Thus, there is no increase or decrease in sizing on the client partition for a known task. These sizing techniques do not anticipate combining the function of shared Ethernet with the Virtual SCSI server. If the two are combined, consider adding resources to account for the shared Ethernet activity with Virtual SCSI .
The amount of processor entitlement required for a Virtual SCSI server is based on the maximum I/O rates required of it. Because Virtual SCSI servers do not normally run at maximum I/O rates all of the time, the use of surplus processor time is potentially wasted when using dedicated processor partitions. In the first of the following sizing methodologies, you need a good understanding of the I/O rates and I/O sizes required of the Virtual SCSI server. In the second, we will size the Virtual SCSI server based on the I/O configuration.
The sizing methodology used is based on the observation that the processor time required to perform an I/O operating on the Virtual SCSI server is fairly constant for a given I/O size. It is a simplification to make this statement, because different device drivers have subtly varying efficiencies. However, under most circumstances, the I/O devices supported by the Virtual SCSI server are sufficiently similar. The following table shows approximate cycles per second for both physical disk and logical volume operations on a 1.65 Ghz processor. These numbers are measured at the physical processor; simultaneous multi-threading (SMT) operation is assumed. For other frequencies, scaling by the ratio of the frequencies (for example, 1.5 Ghz = 1.65 Ghz / 1.5 Ghz × cycles per operation) is sufficiently accurate to produce a reasonable sizing.
| Disk type | 4 KB | 8 KB | 32 KB | 64 KB | 128 KB |
|---|---|---|---|---|---|
| Physical disk | 45,000 | 47,000 | 58,000 | 81,000 | 120,000 |
| Logical volume | 49,000 | 51,000 | 59,000 | 74,000 | 105,000 |
Consider a Virtual I/O Server that uses three client partitions on physical disk-backed storage. The first client partition requires a maximum of 7,000 8-KB operations per second. The second client partition requires a maximum of 10,000 8-KB operations per second. The third client partition requires a maximum of 5,000 128-KB operations per second. The number of 1.65 Ghz processors for this requirement is approximately ((7,000 × 47,000 + 10,000 × 47,000 + 5,000 × 120,000) / 1,650,000,000) = 0.85 processors, which rounds up to a single processor when using a dedicated processor partition.
If the I/O rates of the client partitions are not known, you can size the Virtual I/O Server to the maximum I/O rate of the storage subsystem attached. The sizing could be biased toward small I/O operations or large I/O operations. Sizing to maximum capacity for large I/O operations will balance the processor capacity of the Virtual I/O Server to the potential I/O bandwidth of the attached I/O. The negative aspect of this sizing methodology is that, in nearly every case, more processor entitlement will be assigned to the Virtual I/O Server than it will typically consume.
Consider a case in which a Virtual I/O Server manages 32 physical SCSI disks. An upper limit of processors required can be established based on assumptions about the I/O rates that the disks can achieve. If it is known that the workload is dominated by 8096-byte operations that are random, then assume that each disk is capable of approximately 200 disk I/O operations per second (15k rpm drives). At peak, the Virtual I/O Server would need to serve approximately 32 disks × 200 I/O operations per second × 120,000 cycles per operation, resulting in a requirement for approximately 0.19 processor's performance. Viewed another way, a Virtual I/O Server running on a single processor should be capable of supporting more than 150 disks doing 8096-byte random I/O operations.
Alternatively, if the Virtual I/O Server is sized for maximum bandwidth, the calculation results in a higher processor requirement. The difference is that maximum bandwidth assumes sequential I/O. Because disks are more efficient when they are performing large, sequential I/O operations than they are when performing small, random I/O operations, a higher number of I/O operations per second can be performed. Assume that the disks are capable of 50 MB per second when doing 128 kb I/O operations. That situation implies each disk could average 390 disk I/O operations per second. Thus, the amount of processing power necessary to support 32 disks, each doing 390 I/O operations per second with an operation cost of 120,000 cycles (32 × 390 × 120,000 / 1,650,000,000) results in approximately 0.91 processors. Consequently, a Virtual I/O Server running on a single processor should be capable of driving approximately 32 fast disks to maximum throughput.
Defining Virtual SCSI servers in shared processor partitions allows more specific processor resource sizing and potential recovery of unused processor time by uncapped partitions. However, using shared-processor partitions for Virtual SCSI servers can frequently increase I/O response time and make for somewhat more complex processor entitlement sizings.
The sizing methodology should be based on the same operation costs for dedicated partition I/O servers, with added entitlement for running in shared-processor partitions. Configure the Virtual I/O Server as uncapped, so that, if the Virtual I/O Server is undersized, there is opportunity to get more processor time to serve I/O operations.
Because I/O latency with Virtual SCSI can vary due to a number of conditions, consider the following if a partition has high I/O requirements:
Memory sizing in Virtual SCSI is simplified because there is no caching of file data in the memory of the Virtual SCSI server. Because there is no data caching, the memory requirements for the Virtual SCSI server are fairly modest. With large I/O configurations and very high data rates, a 1 GB memory allocation for the Virtual SCSI server is likely to be sufficient. For low I/O rate situations with a small number of attached disks, 512 MB will most likely suffice.
Subscribe to this information