Povestea timpului pierdut sau schimbarea mintii cu virful timpului, weblogul lui konstantin leontiev

Nu am luat-o de ceva vreme ... dame.

Așa cum mulți pot ghici, în practica mea de proiecte de infrastructură întâlnesc în mod constant diferite lucruri interesante și complexe, dar nu vreau întotdeauna să scriu despre ele și doar timpul / efortul nu este întotdeauna suficient pentru tot. Cu toate acestea, despre acest fapt remarcabil, încă nu pot rezista și spune ...







[Mai departe, pentru a conspira și a respecta regulile de decență, toate faptele, cu excepția celor tehnice, se schimbă]

Și acum grupul este asamblat, DBMS-ul este instalat și a pornit operațiunea pilot / regulat. Toată lumea este fericită și se pare că totul funcționează. Și apoi unul dintre inginerii tăi curioși are o întrebare - ce evenimente ciudate de la sursa lui w32time cu codul 50 apar în revista ... Și evenimentele sunt într-adevăr ciudate:

ID eveniment: 50
Sursa: W32time
Tip: Atenție
Serviciul de timp a detectat o diferență de timp mai mare de 5000 milisecunde timp de 900 de secunde. Diferența de timp poate fi cauzată de sincronizarea cu surse de timp cu precizie redusă sau cu condiții de rețea suboptimale. Serviciul de timp nu mai este sincronizat și nu poate oferi timp altor clienți. Când se primește o ștampilă de timp validă de la un furnizor de servicii.







Și apoi te întrebi, de fapt, ce ar fi? ... Căutarea pe Internet și analizarea Microsoft KB și a altor surse de claritate nu are loc. Aveți cele mai recente actualizări. În general, clusterul este sincronizat cu cel mai apropiat PDC, care se află în aceeași rețea gigabit ca și clusterul.

Apoi, faceți un simplu lucru aparent - includeți compararea timpului pe o gazdă a clusterului cu un anumit tip de controler de domeniu folosind comanda:

w32tm / stripchart / computer: / dataonly

și vedeți că, spre deosebire de observațiile obișnuite, când diferența de timp plutește statistic în jurul unei valori constante, valoarea deviației medii variază prea repede pentru dvs. Ce este prea rapid - de exemplu, la o rată mai mare de 2-3 minute pe zi. De fapt, în cazul unui grup, chiar și 2-3 minute pe zi este prea mult. Ar trebui să explic că la o viteză de aproximativ 15-20 de minute pe zi - situația este pur și simplu critică și necesită o soluție imediată. În cazul meu, au fost exact acele comenzi de "timp" drift (Time Drift).

Voi întrebați și ce consecințe pot exista cu o rată atât de mare de scurgere? Ei bine, să le imaginăm:

Desigur, puteți merge într-un mod simplu și setați o sincronizare agresivă de timp, de exemplu:

Cu toate acestea, o astfel de soluție temporară / rezolvare nu oferă o înțelegere a cauzei principale a problemei și, în plus, poate conține anumite probleme care ar putea apărea în viitor.

Descrierea acestei chei și unele probleme care necesită utilizarea ei sunt date aici:

Ce trebuie să faceți în această situație:

În plus, această problemă poate fi foarte activă atunci când se utilizează virtualizarea.







Trimiteți-le prietenilor: