On 4/10/2013 9:15 AM, Muhammad Yousuf Khan wrote: > actually what i need is 4GB LAN throughput with teaming (802.3ad) for data > storage to backup VMs and same huge data manipulations will be done. so > just confused if it going to work or not.
Addressing the bonded ethernet issue: 802.3ad LACP configured at the switch and within the Linux bonding driver will facilitate TRANSMIT TCP stream load balancing. However, it does nothing to address RECEIVE load balancing. Your application is a ~100% receive workload. So LACP is out. Linux balance-alb is required to achieve any level of receive load balancing. It does not require bonding support in the switch. And it only works with IPv4. See: https://www.kernel.org/doc/Documentation/networking/bonding.txt Addressing the storage issue: RAID6 only has good write performance in a single scenario: large single streaming writes, such as video recording, large file backup, etc. If your writes are smaller than stripe width you incur read-modify-write cycles. These can triple (or more) the number of heads seeks per drive required to complete the write, and you suffer the extra rotational latency in between the seeks. Thus if you're performing multiple partial stripe width writes in parallel, then your performance, even with expensive hardware, will drop into the teens of MB/s. And if you're doing multiple streams RAID6 isn't suitable simply due to the extra head seek and rotational latency of double rotating parity writes. So if you're serious about achieving an aggregate 400MB/s of write throughput to the array, with this workload, you're very likely not going to get there with 8x 7.2K SATA drives in RAID6. Depending on how many concurrent backup streams you're running, and what filesystem you're using, you might get close to 400MB/s using 10 drives in RAID10. The more concurrent jobs, the more spindles you need to mitigate the extra seeks. This will also greatly depend on your backup job write pattern, and thus the chunk/stripe width you select for the array. The RAID parameters must match the application write pattern or performance may be horrible. And lastly, select the right filesystem for the job. EXT3/4 are not suitable for large parallel streaming writes. You will likely need XFS for this workload for optimal performance, and you'll need to align the filesystem to the md/RAID stripe parameters during mkfs. If you're directly formatting the md/RAID device, mkfs.xfs will query the kernel and configure proper alignment automatically. If you use LVM between md/RAID and XFS then you'll need to do manual alignment during mkfs.xfs. Parting thought: It's very easy to get 400MB/s write throughput from an 8 SATA drive md/RAID6 array when doing single streaming writes from 'dd' or other simple one dimensional tests. However, achieving 400MB/s with real workloads is a completely different matter and much more demanding. Most of the md/RAID throughput data you'll find via Google comes from these one dimensional simplistic tests. Don't trust this information. Look for specific workload tests or synthetic benchmark data from bonnie, iozone, etc. While these won't precisely mimic your workload, they give a much better picture of potential real world performance. And the numbers will always be much, much smaller than 'dd' numbers. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5165db76.8010...@hardwarefreak.com
