Otazka znela: Je mozne dostat 10G z existujucich serverov?
Prvotny test 1G prenosu suboru vykazoval vysledok 40MB/s (320Mb/s).
10G prenos suboru bol s vysledkom 70MB/s (560Mb/s), co nieje 10x zlepsenie.
Je vseobecne jasny fakt, ze 10G siet negarantuje 10G applikacny prenos. Napriek tomu bola otazka, ci je mozne realizovat prenos lepsie.
Cielom bola maximalizacia nativneho a hlavne virtualizovaneho prenosu cez 10GbE.
Test na fyzickom hardware
Prva cast prebiehala na fyzickom hardware:
Xeon CPU X5560 @ 2.8 GHz (8 cores, 16 threads); SMT, NUMA, VT-x, VT-d, EIST, Turbo Enabled (default in BIOS); 24GB Memory; Intel 10GbE CX4 Server Adapter with VMDq
Pouzite aplikacie:
Netperf(common network micro-benchmark)
rsync(standard Linux file transfer utilities);
OpenSSH
HPN-SSH (optimized version of OpenSSH) – vyvyjana na Pittsburg SuperComputing Research Center (http://www.psc.edu/)
bbcp(“bit-torrent-like” file transfer utility)
– Stanfort SLAC National Accelerator Laboratory point-to-point network file copy application, like Torrent technology (http://www.slac.stanford.edu/~abh/bbcp/)
Testovaci OS RHEL 5.3 64-bit
Ramdiskused, not disk drives, focused on network I/O, not disk I/O.
Co bolo prenasane: Directory structure, part of Linux repository: ~8G total, ~5000 files, variable file size, average file size ~1.6MB
Nastroj pre zber udajov bol Linux utility “sar”: zber informacii ohladne prijatej prenasanej sietovej prevadzky a CPU vytazenia.
Vysledky Netperf testu:
Netperf odhalil nespravny slot zapojenia 10GbE karty. Pre optimalne vyuzitie 10GbE je nutne pouzit PCIe Gen1 x8.
Netperf je vyborna utilita na zistenie ci mate PCIe na 8x, cize dobre odkomunikovat s vendorom, ako su zapojene PCIe!
Netperf ukazal plny prenos 10GbE, co je ale len teoreticky, umely test.
Zakaznik ocakaval prenos do 600MB /s, kedze uz testoval FTP, ktore malo dany vykon.
Threads
SCP, RCYNC over SSH – aplikacie, vyvijane pre rokmi. Dnes je moznost vyuzivat viacero threads. SCP nedokaze pouzivat viact hreads.
SSH - SCP cez SSH pouziva one active thread, RSYNC ma dva active threads.
Dnes je na 10GbE moznych 16 threads.
SCP cez HPNSSH protocol - Pittsburg Supercomputing Center – bol vyvijany pre long distance high perf links zvacsenim buffer. 4 threads for crypto prevadzku.
Len malo Linux distribucii ma implementovanych HPNSSH.
BBCP – BitTorent – Stanford University – dokaze rozdelit velke packets na paralelnu prevadzku. No encrypt bulk transfer, just handshake. Pri ostatnych sa len mohlo vypnut crypto pre zvysenie vykonu.
Pri teste sa realizovalo zatazenie cez 8 streams.
Netperf iba chceckuje, SCP, RSYNC, BBCP robili realny transfer. Cielom bolo v testoch dostat sa na uroven vysledku NETPERF umeleho testu.
Test ukazal, ze kryptovanie vyrazne zvysuje CPU utilizaciu az na 90%!!! Bez crypto ide CPU na 50%. BBCP na 30%. Intel nabada vyvojarov aplikacnych nastrojovna pouzivanie viac threads. Podpora pre enkrypcne instrukcie je implementovana v novom CPU Intel Westmere napomoze k zlepseniu vykonu sietovej enkryptovanej prevadzky.
Nastavenia BIOS je potrebne zapnut – NUMA,SMT,Turbo – nevadia, troska vedia pomoct.
MultiQueue (VMDq queue virtualization) 16-32 queues for parallel tasking
5.3 enable for RX on RHEL, 6.0 bude mat .
TX is currently limited to one queue in RHEL, SLES 11RC supports MQ Tx
SCP,SSH 1 active thread
RSYNC – only 2 active thread!
HPNSSH – 4 crypto layers, MAC layer limitation, 2 crypto threads, takze 3 zo 16
Viacere paralelne streams su nutne pre prekonanie limitov aplikacii a nastrojov pre maximalny vykon.
Velkym limitom je hruba kryptograficka vykonnostna uroven.
Virtualized Case
Zmena oproti fyzickemu bola, ze jeden Virtualny Pocitac (VM) moze mat max. 8 vCPU.
Pri 8vCPU pri SCP,RSYNC bez kryptovania, ako aj pri BBCP klesal prenos z 9000Mbit na 5800Mbit. S pouzitim kryptografie, pri klasickom SCP, RSYNC cez protokol HPNSSH, alebo s pouzitim SSH je rozdiel medzi physical a virtual mensi. Pri krypto pri SCP cez HPNSSH zapnutom bola 16CPU fyzika lepsia ako 8vCPU vo VM o tretinu. Pri 8CPU vs 8vCPU by to bolo tesnejsie!!!
Ovela lepsie je pustit 8 VMs po 1vCPU, je tak dosiahnuta mensia strata oproti fyzike. Pri SCP over HPNSSH je uz strata stvrtina, ale voci 16 CPU fyzickemu stroju !!! Cize viacero VMs robi lepsi prenos ako jedna velka VM!!!!! Niekedy su lepsie 2vCPU vs 1vCPU machines.
VMDq – frontovanie queues zalozene na threads – traffic load distributed preneseny z hypervisor na physical NIC.
Techniky NetQueue a VMDq realne pomahaju len ak je komunikujucich viacero VMs.
Vmdirectpath pre viacero VMs dedikovane na jeden IO hardware – bude podpora v novych sietovych kartach.
Pri teste neboli pouzite Jumbo Frames, zemerali sa na default sietovy setup. Jumbo je zamerany na storage network iSCSI, NFS!!! Toto bol test SCP,RSYNC. Chceli testovat default out of the box. Uvedomuju si, ze na tuning a upravy je potrebne mat ludi. Existuje vela moznosti pre tuning, ale chceli out of the box technologies.
Predpoklad je, ze jumbo frames by mali napomoct k zvyseniu vykonu v rozmedzi 0-20%.
Netperf sa ukazal ako vhodny identifikacny tool. Nieje ale vhodny pre real workloads. Neda sa len pustit benchmark, musi sa testovat realna aplikacia – priklad je SCP, RSYNC cez SSH.
Nastroje by mali utilizovat viacero threads. Dnes bezne pouzivane aplikacie vykazuju velke hodnoty idle,cize nepracuju efektivne, co vychadza z ich historickeho povodu designu.
Pre nizku latenciu je doporucena kabelas Twinax, SFP Twinax alebo optika, pre nizku latenciu.
Resume:
Najdolezitejsim prvkom testovania sietovych technologii je samotna aplikacia, respektive nastroj operacneho systemu. Stratovy vykon virtualizovaneho prostredia je voci fyzickemu vykonu nizky. K minimalizacii rozdielov vykonov medzi fyzickym a virtualnym nasadenim prispievaju technologie na urovni hardware. Zaverom zakaznik jednoznacne doporucuje virtualizovat.
Zdroj: Achieving 10+ Gbps File Transfer Throughput Using Virtualization - End-User Case Study
http://www.vmworld.com/docs/DOC-3820
Príspevky
Žiadne komentáre:
Zverejnenie komentára