Ekspertips for å flytte vCenter til en ny SQL Server

Vi har alle satt opp test vCenter-installasjoner og brukt den innebygde Microsoft SQL Server Express-motoren. Det er en fin måte å komme i gang for å teste denne eller den funksjonen til vCenter før du prøver den i produksjonen. For et produksjonsmiljø har jeg alltid foretrukket å utnytte en delt (eller sentralisert) SQL Server for å være vert for databasen. Primært er de lettere å administrere på tvers av alle databaseinstallasjoner (for emner som SQL Server-oppdateringer og servicepakker). Som en sekundær fordel er det mindre kostnader ved å ha et antall virtuelle maskiner utstyrt med ekstra minne- og CPU-ressurser dedikert til å ha flere SQL Server Express-installasjoner som kjører rundt.

SQL Express-motoren som leveres med en standard standardinstallasjon av vCenter Server, er ideell for maksimalt 50 virtuelle maskiner på 5 verter eller så. Det er ikke en håndhevet grense, men ting begynner å bli rart hvis du overskrider dette området. Og hvis et test vCenter Server-miljø trenger å flytte over til en delt database, er det noen tips å huske. Dette kan også være et godt skritt å gjøre før du oppgraderer til vSphere 5.

Det første trinnet er å bli kjent med VMware KB 1028601. Selv om denne kunnskapsbase-artikkelen har de fleste av de kritiske trinnene, er det noen få ytterligere hensyn. Først av alt er flyttingen av en SQL-database enklere enn den ser ut til. KB-artikkelen anbefaler ruten for å kopiere filene (SQL .LDF og .MDF) og knytte dem til et nytt SQL Server-system. Dette er en annen tilnærming enn en sikkerhetskopi og gjenoppretting av databasen.

Den andre viktige tingen er å ikke hoppe over vCenter-installasjonstrinnet. Dette kan virke unødvendig eller til og med risikabelt, men det er avgjørende å gjenskape SQL Server Agent-jobbene og utvide databaseskjemaet (om nødvendig) på den nye serveren. Merk at standard SQL Express-motoren ikke har en SQL Server Agent-evne, så dette trinnet bør ikke utelates, som beskrevet i KB.

Hvis du bruker tjenestekontoer, bør vCenter Server-tjenestekontoen legges til som en DBO-rolle i databasen på SQL-serveren. Dette kan settes opp med ODBC-tilkoblingen (kjøres som servicekontoen) og vil bli brukt til databasetilkoblingen.

Når databasen er flyttet, bør en annen standardkonfigurasjon adresseres. SQL Server Express-databasen for vCenter har databaseloggingen konfigurert for en begrenset loggfilstørrelse på 500 MB. Avhengig av hvordan du sikkerhetskopierer vCenter Server (sikkerhetskopierer du den, riktig?), Kan SQL Server-loggene bli behandlet. Dette kan skje via SQL Server scripting eller via logghåndtering gjennom en teknologi som Windows Volume Shadow Copy Service (VSS). Tenk på loggfilen som en beholder som er fullstendig tildelt, til standard 500 MB. Loggføring av databaseaktivitet vil fylle den opp, og deretter vil sikkerhetskopier eller andre logghåndteringsmekanismer fjerne loggingen i den beholderen. (Dette kan også være på tide å bytte fra standardalternativet for enkel logging til full logging, vanlig med de fleste SQL DB-servere.) Som en egen oppgave kan du krympe loggfilene for å gjøre loggfilen mindre, avhengig av loggen. filbehandling (sikkerhetskopiering eller annet), kan det hende at denne 500 MB-beholderen for logging ikke er nok.

Figur A

VCenter-databasen med standardstørrelse på 500 MB logg med begrenset vekst

Hvis databasen flytter til en delt SQL Server-database, kan SQL Server DBA eller serveradministrator ha en policy om håndtering av loggfiler, men ett skritt å vurdere er å la loggfilene vokse ubegrenset for å unngå å fylle ut .LDF fil. Hvis loggfilen fylles ut, vil du stoppe vCenter Server-tjenesten, og følgende melding vises i applikasjonsloggen:

 Et uopprettelig problem har oppstått ved å stoppe VMware VirtualCenter-tjenesten. Feil: 

Feil VdbODBCError (-1) "ODBC-feil: (42000) - Microsoft SQL Server Native Client 10.0

SQL Server Transaksjonsloggen for databasen 'VIM_VCDB' er full.

Hvis databasen tillater automatisk vekst av loggfilen, kan denne meldingen unngås. Imidlertid må håndteringen av loggfilene tas opp. Generelt sett bør databasefilen vokse over tid; men loggfilen skal administreres og beskjæres.

Når databasen er flyttet, kan du sette inn noen få andre praksispunkter for å sikre at det ikke er problemer med vCenter Server som har databasetilgang. Dette inkluderer å sørge for at ting som Windows Server-oppdatering og oppdatering av vinduer er på linje mellom de to systemene. Dette vil sikre at vCenter Service har tilstrekkelig tilgang til databasen. En annen vurdering er å flytte databasekompatibilitetsmodusen fra SQL 2005 til SQL 2008. Dette er vanligvis tilfelle da vCenter installerer SQL 2005 Express, men hvis en ny SQL Server brukes for en hostet vCenter-database, ville SQL 2008 være valget.

Å flytte SQL-databasen fra en frittstående vCenter Server med SQL Express er et viktig trinn, og i mange miljøer er den enkleste konfigurasjonen vokst frem. Har du noen tips om hvordan du flytter vCenter-databasen? Del kommentarene nedenfor.

© Copyright 2021 | pepebotifarra.com