Servere Hyper-V asociate unui domeniu

Toți clienții mei sunt mic afaceri care încearcă doar să se descurce. Fără bugete corporative pentru a face lucrurile într-un mod complet corect, fără multă răsucire a brațelor și puțin timp pentru a construi încrederea.

Un scenariu comun este de a moșteni un site cu un singur server fizic care rulează câteva servere virtuale. Această gazdă Hyper-V este de obicei într-un grup de lucru. Alteori este alăturat domeniului, DC rulând ca una dintre VM-urile sale.

Scenariul domeniului facilitează gestionarea, dar ideea ca controlerul de domeniu să scadă pare problematică. Am văzut un caz în care DC VM nu a fost setat să pornească întotdeauna automat. Am prins asta înainte de a închide gazda pentru întreținere extinsă. De asemenea, mi-am dat seama că parola de administrator al domeniului a fost schimbată recent, așa că ar putea exista o problemă de conectare la gazdă dacă DC nu rula și nu existau acreditări în cache.

Majoritatea site-urilor mici nu au bugetul necesar pentru a cumpăra un al doilea server fizic și mă pun pe mine să configurez DC-uri pe ambele, chiar dacă îl recomand. Pot fie să-și îndepărteze afacerea, fie să fac niște compromisuri pentru a face tot ce pot cu ceea ce își pot permite.Dar chiar nu-mi place starea aleatorie a domeniului/grupului de lucru a gazdelor fizice de la site la site.

Este situația de mai sus cu DC ca VM o problemă serioasă? Ar putea prelungirea perioadei de nefuncționare a CC să creeze o situație, așa cum am menționat-o, în care nici măcar nu vă puteți conecta la gazdă pentru a porni sau repara CC?

Singurul controler de domeniu poate fi un invitat pe o VM Hyper-V, iar gazda poate fi un membru al domeniului.

O întrebare mai fundamentală: poate organizația să accepte acest nivel de disponibilitate în cel mai rău caz? Efectuați un exercițiu de continuitate a activității care să demonstreze că AD DS poate fi restabilit și impactul unei astfel de întreruperi.

• Confirmați acreditările de administrator local pe gazdă.
• Închideți DC și pretindeți că este stricat.
• Creați un invitat DC de testare, din orice hardware suplimentar este la îndemână, un desktop dacă este necesar. Izolați-l complet de rețea, conform celor mai bune practici AD DS pentru un laborator de testare.
• Restaurați DC-ul, din orice copii de rezervă disponibile, pe DC-ul de testare.
• Testează aplicațiile pe DC real, inventarează ce s-a stricat. Parolele memorate în cache ar trebui să funcționeze, dar nu modificările utilizatorilor sau căutările în director. Dacă DNS este inactiv, multe lucruri nu vor funcționa.
• Test de oprire DC, pornire DC de producție.

Un oaspete DC ar putea fi bine. Ușor de gestionat. Economii. Câteva ore mai jos dacă se întâmplă cel mai rău și domeniul este aruncat la gunoi, presupunând că backup-urile sunt bune.

În cazul în care impactul nu este acceptabil, prețul pentru disponibilitate ridicată este un alt DC.Desigur, asta crește costurile pentru hardware, software și complexitate.

Hyper-V nu are nevoie ca domeniul să fie accesibil pentru a porni și a porni mașinile virtuale. Asigurați-vă că aveți un cont de utilizator de administrator local pe gazdă cu care vă puteți conecta la gazdă dacă este necesar.

Am văzut o mulțime din fiecare scenariu și, personal, nu mi se pare mare lucru.

Nu avea mai mult de un controler de domeniu este o problemă mai mare pentru mine decât dacă gazda Hyper-V este sau nu conectată la domeniu.

Scenariul domeniului face managementul mai usor, dar ideea domeniului coborârea controlerului pare problematică.

Nu, total nu. De fapt, este un scenariu acceptat care a fost introdus într-una dintre versiunile anterioare, chiar și pentru clustering (și ASTA a fost problematic, deoarece clusterul nu putea porni fără un controler AD - acum pot).

Nu există absolut nimic despre asta care să nu fie acceptat ca configurație standard de ani de zile.

Am văzut un caz în care DC VM nu a fost setat să pornească întotdeauna automat.

Unii oameni sunt idioți. Și nu configurarea unui DC ca pornire automată fără un motiv întemeiat este în această categorie. Acesta nu este un argument. Am văzut odată o mașină arzând - asta nu înseamnă că nu a fost o problemă tehnică.

Majoritatea site-urilor mici nu au bugetul necesar pentru a cumpăra un al doilea server fizic

Îmi pare rău, este o ceartă la fel de proastă. Acestea sunt aceleași site-uri care se plâng ca nebunii - în momentul în care primul server eșuează, iar hardware-ul NU. Dacă afacerea dvs. depinde de un server, cât de repede este cel de-al doilea server mai scump decât să plătiți oameni sau să închiriați pentru o altă activitate comercială? Același nivel de argumentare de genul „nu facem copii de rezervă” - nimic de-a face cu corporative (ACEI au destule de rezervă) ci cu bunul simț.

Pot fie să-și îndepărteze afacerea, fie să fac niște compromisuri pentru a face tot ce este mai bun Pot cu ceea ce își permit ei.

Îndepărtează-le de afaceri. Dacă afacerea DVS nu depinde de asta, refuzul de a face o muncă nesăbuită nu are nicio implicație pentru sănătatea dumneavoastră financiară.

Este situația de mai sus cu DC ca VM o problemă serioasă?

Îmi pare rău, dar având în vedere că este un scenariu standard documentat... care se reduce la „cât știți despre mașinile cu care lucrați”. A fost odată un hack, de atunci a fost standardizat.,

Timpul de nefuncționare extins la DC ar putea crea o situație precum am menționat în cazul în care dvs nici măcar nu ați putut să vă conectați la gazdă pentru a porni sau repara DC-ul?

Dacă nu sunteți suficient de atent și dezactivați parola de administrator local care poate servi ca punct de acces de urgență (și care nu ar trebui să fie dezactivată niciodată într-un scenariu fără multe copii de rezervă) și aceasta NU există în momentul în care nu rulați AD pe mașină ....nu exista niciun risc.