Funny testing cu disk-uri in RAM

Mi-am găsit distracție pentru sfârșitul ăsta de săptămână: am să verific pe cât de rapidă poate poate fi memoria RAM atunci când o parte din ea e transformată într-un disk logic. Scenariul testat mai jos e cam lipsit de valoare în practică, totuși pentru amuzament merită.  N-o să vă povestesc prea multe despre ce este un disk RAM, am să zic doar că e un disk virtual cu suport pentru stocare organizat in memoria RAM, e super-fast și are un throughput net-superior in raport cu disk-urile mecanice și chiar și cu SSD-urile.  E și clar: no mechanical parts, plus un throughput la viteza magistralei de date a PC-ului. Legat de subiect mi-am adus aminte de un calcul interesant făcut de autor in Mastering VMware vSphere 5 (pag. 544) care după ce compara timpii de acces (seek time) pentru RAM, SSD și HDD – corespunzător de 10ns, 500us și respectiv 8ms continuă cu a raporta diferențele la o secundă de acces pe RAM:

RAM is accessed 800.000 times faster than traditional rotation disk or 50.000 times faster than SSD. Or to put it another way, if RAM takes 1 second to access, the disk could take 800.000 second to access – or nine and a quarter days …

  • HDD: ((800.000/60 seconds)/60 minutes)/24 hours = 9.259 days
  • SSD:((50.00/60 seconds)/60 minutes)/24 hours = 0.5 days

Pe scurt, ceea ce accesezi din RAM timp de o secundă, pe disk îți ia 9 zile iar pe un SSD jumate de zi !!!

Unde folosim un disk in RAM ?

La drept vorbind cam puține use case-uri, mai multe pentru că un disk in RAM e volatil și ca și RAM-ul: stochează până deconectezi PC-ul (alternativ, unele soluții propun opțiuni de backup pe disk-uri rigide: manual/automat/full/incremental). Din ce am auzit eu se mai aplică pe: (1) Visual Studio configurat cu temporary folder pe un disk în RAM –> timp la compilare redus (2) Gaming (3) Photoshop … ș.a.m.d. Din aplicații mai serioase am dat de recomandarea dintr-un document-ul SolarWinds (pag.7) care ca soluție recomandă migrarea fișierelor log (tempdb) SQL pe disk-uri in RAM:

Using RAMDisk® for SQL log (temp)

RAMDisk, a third party software package, allows you to place the temp SQL files onto a logical drive that exists completely in RAM. This requires 64-bit SQL and a good amount of RAM. See the RAMDisk documentation for further requirements. This tool is very useful as it takes the most performance intensive part of SQL storage and moves them from physical disk performance levels to RAM performance levels. Physical drive (spindle) IOPS are measured in the hundreds per second where RAM IOPS are measured in the hundreds of thousands per second.

Și asta printre puținele aplicații mai serioase in producție, in rest nu prea știu … 

Ce soluții există pentru software de disk in RAM ?

Există o mulțime, care gratuite care pe bani, unele cu multiple funcșii altele mai pușine, nu vreau acum să fac o analiză peste ele. Pentru o analiză peste mai multe soluții de disk in RAM (17x), vedeți aici (link) – cei drept cam outdated, 2009, dar totuși. Ce o să folosim noi in lab e soluția StarWinds, distribuită  gratuit și care poate fi descărcată de aici: (link). Simplu de utilizat, in principiu ales la întâmplare. 

Care va fi scenariul pentru teste ?

O să încercăm o arhitectură cu VM-uri pe un host ESXi – host cu ceva rezerve bune de RAM liber, in care intr-un VM cu SO Windows Server 2K12R2 vom configura un disk in RAM peste care vom face teste de IOPS-uri și bandwith. Și ca să facem lucrurile și mai interesante (și de acum lipsite de orice aplicabilitate in practică 🙂 ) o să încercăm ca pe serverul Windows să ridicăm rolul de target de iSCSI cu care vom prezenta un volum LUN creat pe disk-ul din RAM însuși host-ului de virtualizare ESXi și peste care vom crea un datastore VMFS. Pe acesta din urmă o sa încercăm un setup cu Windows XP din curiozitate să vedem cât durează (pur subiectivă la cât de repede merge setup-ul in RAM in comparație cu unul pe HDD). Pe scurt ar semăna cu diagrama de mai jos:

funny_testing_with_ramdisk_testbed_sch

Configurare disk in RAM

Vom începe prin a crea un VM peste care vom instala aplicația StarWinds pentru RAM Disk și prin intermediul cărui vom crea un disk logic in RAM:

  • Creăm un VM nou pentru care alocam suficient RAM – ne ajung 12GB și 2x vCPU-uri. Deși pe host există suficientă memorie liberă ca să nu concurăm pentru ea cu alte VM-uri, vom rezerva totuși întreaga capacitate (ne asiguram ca testele vor fi minim influiențate): VM Settings – Resources – Reserve all memory (All locked).
  • Instalăm un SO Windows Server. Un 2012 in sus ca să putem mai târziu ridica rolul de target iSCSI.
  • Descărcăm (link aici) și instalăm StarWinds RAM Disk. Simplu de tot: Next – Next-… Finish. Interesant că la un moment dat îți instalează un Storage Controller nou – pe acesta vom avea conectat disk-ul in RAM.
  • Din fereastra aplicației, cu ADD device creăm un disk nou in RAM. Configurăm unul ee 8GB (8192MB) fără a aplica un sistem de fișiere pe el: debifăm Create Formated disk – la faza cu IOMeter voi încerca testul pe RAW block device.
  • Disk MGMT, inițializăm cu MBR disk-ul nou creat. MBR pentru că IOMETER lucrează doar cu ăsta nu și GPT.

Test cu IOMeter

Inițiem testul cu IOMeter, pentru care de remarcat, avem deja o distribuție stabilă pentru versiunea 2: IOMeter2 v1.1.0 (download de pe site-ul proiectului). Instalăm IOMeter (banal) după care îl pregătim de test după cum urmează:

  • Disk Targets – selectăm PHYSICALDRIVE:1 – care de fapt e dispozitivul creat in RAM și inițializat anterior cu MBR. Mai nou pentru mine, aflat că IOMeter-ul poate să lucreze direct cu dispozitivele block fără ca pe acestea să fie aplicate un sistem de fișiere (NTFS sau FAT). Interesant e că in așa mod nu mai trebuie să inițializezi fișierul de test (iobw.tst) – care pentru un test trustfull trebuia întins pe toată capacitatea discului și pentru un disk mare iți lua o groaza de timp până se inițializa. 
  • Disk Targets – Maximum Disk Size: 0. Zero pentru toată capacitatea disk-ului. Dacă era să facem testul peste un sistem de fișiere atunci parametru trebuia definească dimensiunea fișierului de test iobw.tst exprimat in număr de sectoare de disk. Un sector = 512B, asa că de ex. pentru un fișier de test iobw.tst de 10GB specifici 10x1024x1024x2 = 20971520 de sectoare pe disk.
  • # of Outstanding  I/Os – fără să intru in detalii, ignorăm pentru dispozitive in RAM. In rest, 32/64.

funny_testing_with_ramdisk_IOmeter_conf_disktargets

  • Configuram pattern-ul de sarcină: Access Specification. Vom aplica un patern folosit drept referință cu un IO caracteristic mai ales pentru datastore-uri de mașini virtuale: (1) Transfer Request Size: 4KB (2) Percent Random/ Sequential Distribution: 80% (3) Percent Read/Write Distribution: 80% (4) Align IO on: 4KB.

funny_testing_with_ramdisk_IOmeter_conf_access_patern

  • Pornim testul și imediat obținem rezultatele cu big numbers.. 🙂 : (1) IO per second: 80.000 – gigantic in comparați cu câteva sute pe HDD-uri. (2) Throughput: câțiva Gbps (x8/1024) și câțiva zeci de Gbps pu block size de 512KB (3) Avg I/O Response Time de 0.01ms (extraordinar in comparație cu zeci de ms la HDD… )

funny_testing_with_ramdisk_IOmeter_results

Din interes am repornit testul dar deja pe celălalt datastore (matrice RAID10 din 6 disk-uri SAS 15k). Pentru test am folosit partiția de Windows pe volumul căreia am creat fișierul de test iobw.tst de 1GB (20971520 sectors) – mai mare avea să aștept zeci de minute până se inițializa. Iată ce a ieșit:

funny_testing_with_ramdisk_IOmeter_results_on_RAID

Cu 3000 de IOPS-uri și latency de 20 ms și acesta e foarte bun, dar totuși la ani lumină de disk-ul in RAM 🙂

Show must go on …

Acum să vedem, cum ar fi sa instalăm un SO Windows XP pe un datastore ESXi in RAM. Încă odată, ceea ce încercăm aici e un nonsens clar practică, tot ce facem e doar just for fun așa că nu repetați in altă parte. Vom continuăm cu:

  • Pe VM-ul cu Windows ridicăm rolul de target iSCSI: Server Manager – Server Roles – File and Storage Server – iSCSI Target Server … 
  • Prin target-ul iSCSI prezentăm un LUN pe care îl vom crea pe disk-ul nostru in RAM: (a) create iSCSI target (b) create iSCSI virtual disk ~ 6GB (c) assign access server – IP-ul interfețe vmk0 ESXi.
  • Pe ESXi configurăm inițiatorul iSCSI pentru LUN-uri prin HBA-ul de iSCSI: (a) Install: Configuration – Storage Adapters – Add .. – Add Software iSCSI Adapter (b) Configure: Dynamic Discovery – Add .. – iSCSI server: IP VM, Rescan.
  • Pe ESXi creăm un Datastore VMFS pe LUN-ul adus prin iSCSI: Configuration – Storage – Add Storage – Disk/LUN – VMFS5/Datastore Name/Maxim Available Space ..
  • Cream un VM pentru un Guest OS pe Windows XP cu disk-ul virtual pe datastore-ul in RAM: (a) New Virtual Machine / Typical / Storage pe datastore in RAM / Guest Windows XP. (b) reconfigure for LSI Logic Paralel / Virtual Disk on IDE.
  • Montam ISO-ul cu setup-ul de XP la VM și pornim procesul de instalare. By the way, și asta e copiat pe datastore-ul in RAM (cu Datastore Browser).

Pornit. Incepe bine și continuă foarte repede, dar totuși parcă e sub la ce mă așteptam eu să vad: un setup super fast de câteva secunde. Pe ESXTOP, in statistica pe datastore-uri am observat un maximum de doar 400 IOPS-uri (CMDS/s), straniu pentru că rezervă ar fi și totuși setup-ul nu prea ia foc – nu pot decât să deduc că există alți factori in plus care au redus viteza procesului de setup, cu siguranță nu RAM-ul e de vina.

Done, nice weekend lab.