Cât de „real” este ceasul POSIX dintr-o mașină virtuală?

Introducere:

Timpul este sistemul de operare, cum Linux este de obicei derivat dintr-un cip de ceas (RTC) sau menținut de software folosind fie întreruperi periodice, fie niște registre hardware (de exemplu, contorul de cicluri TSC al CPU) pentru implementare.

Evident, într-o mașină virtuală nu există acces direct hardware (de exemplu, la RTC), așa că păstrarea orei corecte poate fi dificilă.

În mod specific, mă întreb despre cele două implementări de ceas POSIX: CLOCK_REALTIME și CLOCK_MONOTONIC (mai sunt).

Tulburări

Sunt două „tulburări” majore pe care le iau în considerare:

1. „CPU overcommitting”: oferind mai multe procesoare virtuale mașinilor virtuale decât sunt cele fizice
2. „Migrare live”: mutarea unui VM de la o mașină la alta „fără” a afecta operațiunile

Operatie normala

Procesele care rulează într-un sistem de operare pe hardware nu sunt întrerupte doar de sistemul de operare (care are controlul atunci). Deci sistemul de operare poate păstra ora cu ușurință.

Operarea VM

Un sistem de operare care rulează într-o VM nu are control continuu asupra procesorului. De exemplu, dacă sistemul de operare „nu are CPU”, nu poate procesa întreruperile temporizatorului. La rândul său, acest lucru ar putea duce la pierderea completă a întreruperilor temporizatorului, a fi întârziate cu o cantitate aparent aleatorie (jitter) sau poate chiar să fie procesate într-o secvență rapidă (procesarea întreruperilor „întârziate” acum). De asemenea, ceasul nu ar progresa la fel de liniar cum era de așteptat.

Alegeri

• CLOCK_REALTIME: Dacă sistemului de operare îi lipsește procesorul, ceasul în timp real poate fi fie încetinit (lipsă în urmă), fie să sară înainte ocazional pentru a ține pasul
• CLOCK_MONOTONIC: Dacă sistemului de operare îi lipsește CPU, ceasul în timp real poate fi fie încetinit (în raport cu alte VM-uri sau timp de perete), fie să sară înainte ocazional pentru a ține pasul

Efecte

• CLOCK_REALTIME: Evident, dacă ceasul în timp real este lent, nu poate fi folosit ca măsură de sincronizare absolută, dar ar părea consistent în VM. Dacă ceasul ține pasul saltând înainte cantități variabile de timp, ar putea fi folosit ca măsură absolută, dar ar fi rău pentru măsurarea oricărei performanțe (durate) în cadrul VM.
• CLOCK_MONOTONIC: Avansarea ceasului monoton numai dacă VM-ul „are CPU” va oferi o vedere consecventă a timpului scurs în VM. A face ca ceasul să sară înainte în cantități variabile de timp ar împiedica utilizarea măsurătorilor de performanță (durată) în cadrul VM.

Live-Migration

Când migrarea live necesită copierea gigaocteților de RAM de la un nod la altul, va exista un „timp de înghețare” când VM nu poate rula, să spunem 3 secunde.

Acum, timpul real ar trebui să sară înainte și cu 3 secunde, sau ar trebui să piardă cele trei secunde până când va fi corectat manual sau automat la un moment dat? La fel, atunci când ceasul monoton este folosit pentru a măsura „uptime”, ar trebui să ia în considerare acele trei secunde adăugându-le sau ar trebui să ia în considerare timpul în care VM-ul a avut de fapt procesorul?

CPU supra-angajat

Ca mai sus, dar există întârzieri scurte mai frecvente în loc de întârzieri ocazionale mai mari.

Întrebări

Ce abordare folosește Xen?

Cum se ocupă VMware de asta? Există opțiuni configurabile? (Știu că în Xen VM-urile pot fi sincronizate de la hipervizor sau pot rula independent (de exemplu, sincronizate de la extern folosind NTP))

Există „cele mai bune practici”?

POSIX (și Linux în general) nu a avut niciodată cronometre garantate, în sensul că dacă adormiți ceva, vă puteți aștepta să se trezească la o oră exactă. Puteți garanta vreodată că trezirea a avut loc DUPĂ ora menționată, nu tocmai pe ea și nu înainte de*.

Linux nu este menit să fie în timp real și face tot posibilul.

Din om 2 nanosomn care este compatibil POSIX:

nanosleep() suspendă execuția firului de apel până la oricare macar a trecut timpul specificat în *req sau livrarea unui semnal care declanșează invocarea unui handler în firul apelant sau care încheie procesul.

Dacă vă așteptați ca căpușele să fie de încredere, atunci problema acolo este mai probabil să nu aveți o euristică pentru a gestiona un diapozitiv în interiorul unei anumite ferestre.

Sugestia mea aici ar fi să vă regândiți designul aplicației pentru a fi mai puțin de încredere pentru trezirile exacte sau să aveți un sistem de siguranță în cazul unei întârzieri neașteptate.

IE

• Software-ul se întrerupe din cauza unei anomalii de întârziere.
• Software-ul de trezire observă o diferență în comparație cu o altă sursă de timp autorizată și își „pasează” ideea următoarei treziri pentru a compensa.
• Imprimați un avertisment sau furnizați o altă notificare.

Nu este cu adevărat plauzibil să ne gândim la timp ca fiind de încredere într-un sistem preemptibil. Chiar și pe metalul gol.

• Întreruperile nemascabile nu pot fi blocate.
• Încărcare mare înseamnă că ești doar programat pentru o lungă perioadă de timp.
• Întreruperile la CPU invocate de hardware pot cauza întârzieri.
• Defecțiunile minore și majore ale paginii pot produce întârzieri foarte mari între trezirile temporizatorului.
• Alocarea memoriei pe băncile de memorie nedeținute de către CPU adaugă întârzieri.

Aceasta este într-adevăr doar o funcție a computerului x86 modern.

Cel puțin pe KVM, există o sursă de ceas numită „kvm-clock” care ar trebui să reprezinte tick-uri de la hypervisorul de bază, indiferent de orice întârzieri necunoscute într-un VM. Puteți găsi acel fișier și ceea ce ați setat în această cale: /sys/devices/system/clocksource/clocksource*/current_clocksource și vezi care sunt opțiunile tale /sys/devices/system/clocksource/clocksource*/available_clocksource.

Dar din nou, gazda de bază poate avea propriile întârzieri. Deci sunt doar țestoase până jos...

Nu vă bazați pe garanții în timp real acolo unde nu există. Construiți software-ul fie pentru a face față întârzierilor neașteptate, fie cel puțin să știți despre ele.

NTP, în general, este un întreg protocol menit să rezolve problema timpului, ce oră este „corectă” și ce trebuie făcut pentru gestionarea modificărilor timpului. Este o problemă destul de complicată.

Cea mai bună practică este că doriți să configurați sistemul pentru a face problema improbabilă din punct de vedere statistic, gândiți-vă la ceea ce (dacă există) ar constitui o autoritate de încredere pentru timp în aplicația dvs. și apoi cum doriți să faceți față evenimentelor improbabile în care timpul se schimbă. .

Poate ați configurat un SLA spunând că ora va fi incorectă. 1 verificați 1000000 de mostre. Adică este posibil, deși puțin probabil din punct de vedere statistic, ca căpușele să fie oprite.

Modul în care iau în considerare timpul când lucrez cu grupuri de sisteme diferite, care toate sunt legate, este că este mai important ca localitatea lor de timp* să fie într-o fereastră mică de diferență. În această măsură, aș avea o configurație de server de oră locală care în sine folosește o sursă autorizată, apoi aș avea toate computerele din acel grup să se sincronizeze cu acel sistem local. Latența foarte scăzută la serverul de timp local servește la reducerea fluctuației locale și toate gazdele ar trebui să rămână foarte strâns sincronizate.

• Unele implementări de temporizator folosesc un handler de semnal pentru a capta evenimentele. Adică SIGALRM, dacă trimiteți unui proces un semnal ALRM în afara temporizatorului, acesta se va trezi înaintea acestuia.

• Localitatea aici ar fi toate computerele legate logic între ele, toate se află în, poate, câteva milisecunde de timp unul în celălalt. Dar ele ar putea diferi foarte mult între o altă localitate, adică un grup de sisteme care este latența la 500 ms distanță.