10 Biggies å hjelpe ledere og Admins Unngå Virtualisering Pit-Falls
Jeg ønsker denne informasjonen var tilgjengelig 10 år siden da jeg begynte å arbeide med virtualisering, men så igjen, som mange leser dette, jeg trodde jeg var en ekspert og ikke trenger det. Nå ser jeg meg selv som en student på grunn av hvor raskt virtualisering er i endring.
En. Første og viktigste, se på det store bildet for hvorfor du implementere virtualisering. De fleste ledere ser utelukkende på VMware, XenServer, Hyper-V eller andre virtuelle server produkt for ROI (Return On Investment). Dårlig måte å gjøre det beslutninger! Se på det store bildet. Hvordan vil virtualisering påvirker alt og alle den kommer i kontakt med? For eksempel: Hvordan vil din bagasje bli påvirket når du begynne å dele den med sulten VMs, vil I / O holder opp? Eller, hvordan vil du systemansvarlig håndtere den nye ansvar? Hvordan vil du håndtere brukerne når de begynner å klage over at alt er treg fordi du ikke anser I / O og nye ansvar?
2. Når du har et stort bilde syn på hva du vil gjøre med virtualisering og deretter vurdere at du fortsatt sannsynligvis mangler noen få ting du vil lære underveis. Bare se på disse utfordringene som økende smerter, og uunngåelig. Virtualisering dynamisk endres etter hvert som miljøene vokser og oppgradering. Først er det den eksperimentelle ESX eller gratis ESXi, Hyper-V og XenServer vert som får deg i gang. Så når det eksperimentelle verten (e) blir fylt opp er det den lille gården vert servere som får landet når du faktisk begynne å kjøpe ny maskinvare og hele infrastrukturen lisensene. Pass opp! av "jøss vi kan virtualisere alt" perioden som skjer 50-200 virtuelle servere. På dette punktet alt ser ut til å fungere fint, fordi du ikke har mettet din SAN I / O, eller vert minne og CPU. Men så er det som peker på at skjer på VM nummer 201 (201 er et relativt tall, kan det være mer eller mindre avhengig av en rekke faktorer) hvor panikken er uunngåelig hvis du ikke har forberedt skikkelig. Det er derfor du behov for å lese resten av dette innlegget.
Tre. Nå som hensynet 1 og 2 er ute av veien, som i hovedsak for å gjøre IT-ledere tror, vil jeg komme til godsakene. Ha en backup strategi i begynnelsen som er laget for å sikkerhetskopiere det VM bilder. Ikke stol på eldre dine backup-programvare for fysiske servere. Ja NetBackup eller hva kan fortsatt gjøre agent backup av filer av en VM, dette er en no brainer. Men, er hvordan du skal gjøre en fullstendig systemgjenoppretting? Med mindre det er bare data, fem timer etter at du sikkerhetskopien administratoren begynner systemet restaurere han fortsatt kommer til å være å prøve å løse denne gåten. Du vil ha en god løsning som gjør et bilde sikkerhetskopien. Løsninger: VCB, vRanger Pro, Veeam Backup, Avamar. Disse er alle spesifikke backup verktøy for virtualisering. Avamar kan arbeide på alle typer virtuelt miljø inkludert Sun beholdere.
4. Kjenn dine lagring grenser. Kapasitet er bare en del av lagringsplass kravet. Den andre delen er I / O eller OIPS (Input / Output Per Second). VMs har forskjellige I / O behov. En sulten database eller SharePoint-VM på en LUN som deler det er disk paritet med flere LUNer kan føre til ytelsen problem i alle de LUNer i disken paritet gruppen. Den beste måten jeg har funnet å unngå dette er å utforme lagring med det største I / O basseng tilgjengelig. I / O begynner ved disken og 15K disker har rundt 200 IOPS der 10K disker har 150 IOPS (SATA har 30-50 IOPS). Gjøre regnestykket, noe som er bedre? Etter kapasitet og I / O er regnet, så er det den pathing, som må manuelt konfigurere å splitte I / O ned flere baner til SAN / NAS cache. Jeg har sett millioner dollar utstyr brakt i kne, fordi disse greiene var oversett. Det er vanligvis ikke utstyret (HP, NetApp, EMC) som forårsaker problemet, dens konfigurasjonen. Uansett om du planlegger å bruke FC, NFS eller iSCSI, dette er viktig for lagringen administrator å vurdere. Ellers blir du spille VM-lagring Tetris og jeg garanterer du vil miste.
5. Dette er i forbindelse med 4, VM mal konfigurasjon. Hvis du planlegger å ha en stor pool av I / O så du aldri kan vite malen konfigurasjonen er dårlig. VM konfigurasjonen er viktig og er lett å overse. De fleste vil finne ut hvor viktig når I / O-løper ut ... Jeg har lest denne beste praksis på mange blogger - "putte data og OS, og til og med bytte filer på separate LUNer." Jeg er enig dette er en god beste praksis, men jeg am tar den videre og legge til et kriterium. "Separat LUN på separat disk paritet grupper." Her hvorfor, ti - 15K diskene vil gi deg rundt 1500 IOPS i hvert LUN det er hugget inn. Avhengig av størrelsen på harddisken du kan ha ulike LUN størrelse på 200 til 500 GB (hver med 10 - 20 Jeg / O sulten ABL) deler samme IOPS. Splitting data, OS og bytte ut flere spindler vil gi deg mer IOPS og muligens en annen bane til den andre lagring prosessor (aktiv / aktiv), eller mer buffer som er tilordnet en annen FC eller NIC port. Pass datalageret navn er blant annet hva LUN er for (Data, OS eller bytte) og Odd enda disk paritet (data går på odde, OS begynne selv).
Seks. Rengjør opp søl. Ikke la gamle bevis på konseptet (POC) VMs eller utstyr som kjører etter at POC er gjort. Ingenting er vanskeligere å gjøre da for å rydde opp i en VM-miljø 2 år etter at alle som var på den opprinnelige prosjektgruppen har forlatt og din VM inventar har nå 500 VMs i den. Det første stedet du trenger å se når du treffer din vert og lagring grenser er her. Ut av 500 VMs du kan satse det er minst 50 VM zombier som er uvirksom kjører og bruker opp dyrebar ressurser. Så er det den rene av zombie VM mapper som er fra VM som ble feilaktig slettet, og filene ble etterlatt på datalageret (du vet det VM du sa du ville slette senere - det var 2 år siden). Rydd opp også hjelper kontroll "bre". Bre er et fancy ord for ut av kontroll.
7. Du vil sannsynligvis ikke høre meg den første gangen, så jeg sier "sikkerhetskopier" igjen. Jeg setter denne ned igjen for å sikre at du har en backup løsning som sikkerhetskopierer hele VM bildet. Det er ingen enkel oppgave å endre sikkerhetskopieringen 2 år og 500 VMs senere, så sørg for at du gjør dette riktig fra starten.
Åtte. Etablere en standard for ditt miljø. Alle verter vil være på sertifiserte versjonen av ESX eller hva hypervisor du bruker. Når du tillater gamle verter å si rundt etter at du har besluttet å bygge ny vert på dagens ESX-versjonen, vil det ikke være lenge før din virtuelle infrastruktur er fragmentert. Husk, virtualisering utvikler seg nesten daglig, og nye funksjoner er på hver ny versjon av ESX og Hyper-V. Live migrasjon fungerte ikke på den gamle Hyper-V versjon, men den arbeide med R2, men det fungerer ikke over R1 til R2 eller R2 til R1. Få alle de R1 oppgradert til R2 slik at alle er de samme og live migrering fungerer. Holde standarden er ikke lett fordi VM administrator er også systemansvarlige, har de å lande på serverne, konfigurere verten, samt distribuere VM og konfigurere VM. Det er de samme menneskene gjør både arbeidsplasser og i noen tilfeller er de lagrings-og nettverksadministratorer også. Kontroller at du har nok ansatte til å opprettholde standarder. Jeg har kjent mer enn noen få overarbeidet, underbetalt og savner-forstått VM administratorer i min tid.
9. Jeg hater dette like mye som enhver sant IT-tekniker, men noen må fortsette å gjøre jobben om du legger igjen og ta en bedre betalt jobb et annet sted. Pass på at du holder god dokumentasjon. Hvis det er nødvendig, kult Visio er av alt er hyggelig for ledelsen, men enda viktigere for dag til dag støtte personalet er "hvordan" dokumenter. Slik land og klargjør en vert (maskin-og hypervisor). Hvordan du distribuerer en VM. Hvordan legge til ekstra diskplass til "C"-stasjonen på en VM. Slik P2V et system. Hvordan du skal be om mer lagringsplass. Hvordan til nedstengning en VM. Slik planlegger du en VM backup. Slik gjenoppretter en VM fra en sikkerhetskopi. Også holde "hvordan" dokumenter up-to-date. Du trenger en ny "Slik" for hver versjon av ESX fordi de er ikke det samme, tilpasning til SWAP volumet for eksempel er annerledes på 2.5, 3.0 og 3.5. Hyper-V og XenServer har sin egen lille tweaks også.
10. Ikke kjøp alle verktøyene der ute tenker det kommer til å fikse alt jeg har brukt de siste 2 timene skriver om. Lytt til det jeg sier. Lytt til støttepersonell. Nøye lytte til leverandører som ønsker å selge deg noe, fordi det ikke er sølvkule for dårlig planlegging. Og, mens i emnet leverandøren, noen rådføre anbefaling med direkte forbindelse med utstyrsleverandører bør også gransket. Jeg har sett det beste SAN penger kan kjøpe kollapse under 25 VMs fordi den ble brukt på måfå (VM lagring Tetris). Mange av problemene jeg har advart deg om kan unngås hvis du planlegger. Les nummer 1 og 2 igjen før dette er fornuftig. Til VM administratorer som kjemper den daglige slagene fordi det meste av det jeg har skrevet om er allerede skjer i ditt virtuelle miljø, føler jeg din smerte. Til alle de nye lyse øyne IT-administratorer og system administrator som slikker sine koteletter fordi de er endelig får et budsjett til å starte virtualisere, advarer jeg deg og si: "Tenk på det store bildet og plan, plan, plan!"
Forhåpentligvis kan dette innlegget er nyttig. Andre poster som ikke er dekket er: Hvordan overvåke VM og host-servere, katastrofesikring DR i virtuelle miljøer, kapasitetsplanlegging, prognoser og maskinvare (servere, nettverk og lagring) merker og typer. Disse kan være tema for de neste 10 biggie listen. Mine siste notatet er "sikkerhetskopier" vil utfordre tradisjonell tenkning slik akt mine advarsler.
Opprinnelig postet 2009-03-29 10:38:28. Publiseres ved blogginnlegg Arrangøren
Recent Comments