Nu är det dags igen... Bloggen kommer att vara rätt sporadisk framöver, men om ca fyra veckor är jag tillbaka igen som vanligt.
Känner jag mig själv rätt så komme det dock att komma lite poster då och då, och om inte annat så finns ju alltid twitter (@DiverseTips) . :)
trevlig sommar!!
(BTW: söker ni nått att läsa i sommar så gå in på www.papershare.com och regga ett konto. Jag heter föga förvånande "Bjorn Andersson" där.. Där finns delar av min "att-läsa-lista" för sommaren.)
//Björne
2011-06-28
Varför är det viktigt att dubbelkolla saker ibland...
För ett tag sedan så skulle jag rita upp en bild över hur en virtualiseringmiljö såg ut.
Jag hade en del information från början och därmed en rätt bra bild av hur resultatet skulle bli. Upp med Visio och börja rita.
När jag fått upp grunden så gick jag och dubbelkollade kopplingar och liknande.
Som det ofta är när det gäller kablar så var det inte det lättaste att följa allting men jag gav mig fan på att dubbelkolla så att jag visste att alla kablar verkligen gick till den switch som jag trott.
Mycket riktigt visade det sig att en av hostarna inte var kopplad till den switch som jag trott utan till en helt annan switch. När detta skett vet jag inte, men kontentan var att istället för att få gigabit mellan hostarna så var det 100Mbit för just denna host på detta nät...
Detta i sin tur förklarar varför det tog 5 gånger så lång tid att göra en livemigration från och till just den hosten i jämförelse mot andra hostar.... hosten kopplades om och helt plötsligt så gick det mycket snabbare att flytta VMar.
kontentan av denna post:
- Underskatta inte värdet av att göra revision av hur det verkligen ser ut... ibland sker det förändringar i miljön på ett sätt som det inte är tänkt och ibland glömmer folk att ändra tillbaka saker efter att de gjort en "temporär fix".
en revision behöver inte vara för hela serverparken... det kan vara att man lägger 10 minuter på en sak...
Jag hade en del information från början och därmed en rätt bra bild av hur resultatet skulle bli. Upp med Visio och börja rita.
När jag fått upp grunden så gick jag och dubbelkollade kopplingar och liknande.
Som det ofta är när det gäller kablar så var det inte det lättaste att följa allting men jag gav mig fan på att dubbelkolla så att jag visste att alla kablar verkligen gick till den switch som jag trott.
Mycket riktigt visade det sig att en av hostarna inte var kopplad till den switch som jag trott utan till en helt annan switch. När detta skett vet jag inte, men kontentan var att istället för att få gigabit mellan hostarna så var det 100Mbit för just denna host på detta nät...
Detta i sin tur förklarar varför det tog 5 gånger så lång tid att göra en livemigration från och till just den hosten i jämförelse mot andra hostar.... hosten kopplades om och helt plötsligt så gick det mycket snabbare att flytta VMar.
kontentan av denna post:
- Underskatta inte värdet av att göra revision av hur det verkligen ser ut... ibland sker det förändringar i miljön på ett sätt som det inte är tänkt och ibland glömmer folk att ändra tillbaka saker efter att de gjort en "temporär fix".
en revision behöver inte vara för hela serverparken... det kan vara att man lägger 10 minuter på en sak...
2011-06-27
Uppdatering till XenServer 5.6 SP2... (Buggfix)
Jag har tidigare skrivit om en bugg i ServicePack 2 till XenServer 5.6.
Nu sedan ett par dagar finns det en buggfix för denna.
Den är mandatory för alla som använt uppdateringspaketet. Har man gjort en installation direkt från SP2-cdskivan är det inte nått krav att köra den.
Fast om det så bara finns en enda server som är uppgraderad och alla andra är installerade från SP2 så måste man ändå lägga på patchen på SAMTLIGA servrar... Detta är lite lurigt och gör att eventuellt servicefönster blir längre.
Patchen läggs på Poolmaster först, därefter skall servern startas om, och sedan skall samma sak göras på resten av servarna i poolen.
Ladda ned patchen här, där finns det även en hel del info om hur man gör exakt för att installera uppdateringen.
(jag var tvungen att migrera bort mina VMs från poolmastern, och sedan köra patchen på poolmaster, boota om. Därefter migrera bort VMarna från server 2 osv... dock skall det enligt uppgift funka att låte XenCenter göra allting automatiskt...)
Nu sedan ett par dagar finns det en buggfix för denna.
Den är mandatory för alla som använt uppdateringspaketet. Har man gjort en installation direkt från SP2-cdskivan är det inte nått krav att köra den.
Fast om det så bara finns en enda server som är uppgraderad och alla andra är installerade från SP2 så måste man ändå lägga på patchen på SAMTLIGA servrar... Detta är lite lurigt och gör att eventuellt servicefönster blir längre.
Patchen läggs på Poolmaster först, därefter skall servern startas om, och sedan skall samma sak göras på resten av servarna i poolen.
Ladda ned patchen här, där finns det även en hel del info om hur man gör exakt för att installera uppdateringen.
(jag var tvungen att migrera bort mina VMs från poolmastern, och sedan köra patchen på poolmaster, boota om. Därefter migrera bort VMarna från server 2 osv... dock skall det enligt uppgift funka att låte XenCenter göra allting automatiskt...)
Missförstånd och myter kring Exchange 2010 och High Availability
Ibland springer man på magiskt bra sammanställningar.
Idag hittade jag en sån. Det är Scott Schnoll som återigen skriver en fantastisk sammanfattning om olika missförstånd och liknande kring Microsoft Exchange 2010 och High Availability (HA).
Bloggposten hittar man här:
http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-high-availability-misconceptions-addressed.aspx
Saker som ta upp är bland annat:
Idag hittade jag en sån. Det är Scott Schnoll som återigen skriver en fantastisk sammanfattning om olika missförstånd och liknande kring Microsoft Exchange 2010 och High Availability (HA).
Bloggposten hittar man här:
http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-high-availability-misconceptions-addressed.aspx
Saker som ta upp är bland annat:
- Exchange 2010 High Availability and Site Resilience Terminology
- Misconception Number 1: The Alternate Witness Server (AWS) provides redundancy for the Witness Server (WS)
- Misconception Number 2: Microsoft recommends that you deploy the Witness Server in a third datacenter when extending a two-member DAG across two datacenters
- Misconception Number 2a: When I have a DAG with an even number of members that is extended to two datacenters, placing the witness server in a third datacenter enhances resilience
- Misconception Number 3: Enabling DAC mode prevents automatic failover between datacenters; therefore, if I want to create a datacenter failover configuration, I shouldn’t enable DAC mode for my DAG
- Misconception Number 4: The AutoDatabaseMountDial setting controls how many log files are thrown away by the system in order to mount a database
- Misconception Number 5: Hub Transport and Client Access servers should not have more than 8 GB of memory because they run slower if you install more than that
- Misconception Number 6: A Two-Member DAG is designed for a small office with 250 mailboxes or less
2011-06-23
Har du funderat på VDI? Thin PC to the rescue för klienten.
Microsoft har släppt en produkt som heter Thin PC.
Tanken med Thin PC är att de flesta företag har en massa datorer som man gjort investeringar i. Om man sedan vill köra en VDI-lösning så är det inte alltid ekonomiskt försvarbart att bara slänga alla datorer och köpa in tunna klienter istället.
Det är här som Thin PC kliver in. Det är en liten installation av Windows. Hela nyckeln är att det inte krävs någon Virtual Desktop Access (VDA) licens.
Det går att köra applikationer direkt på Thin PC, men bara vissa sorters applikationer. Exempelvis, säkerhetsapplikationer (antivirus och dylikt), management agenter, Remote Desktop, webbläsare, mediaspelare, .Net framework, Java Virtual Machine och liknande.
Exempelvis Microsoft Office är inte en sådan applikation som går att köra lokalt på Thin PC (men hela idén med en VDI/Tunn klient är ju att ha applikationer typ office centralt :))
Lite mer läsning:
http://windowsteamblog.com/windows/b/business/archive/2011/06/07/windows-thin-pc-rtms.aspx
http://virtualization.info/en/news/2011/06/release-microsoft-windows-thin-pc-1-0.html
http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/thinpc.aspx
Tanken med Thin PC är att de flesta företag har en massa datorer som man gjort investeringar i. Om man sedan vill köra en VDI-lösning så är det inte alltid ekonomiskt försvarbart att bara slänga alla datorer och köpa in tunna klienter istället.
Det är här som Thin PC kliver in. Det är en liten installation av Windows. Hela nyckeln är att det inte krävs någon Virtual Desktop Access (VDA) licens.
Det går att köra applikationer direkt på Thin PC, men bara vissa sorters applikationer. Exempelvis, säkerhetsapplikationer (antivirus och dylikt), management agenter, Remote Desktop, webbläsare, mediaspelare, .Net framework, Java Virtual Machine och liknande.
Exempelvis Microsoft Office är inte en sådan applikation som går att köra lokalt på Thin PC (men hela idén med en VDI/Tunn klient är ju att ha applikationer typ office centralt :))
Lite mer läsning:
http://windowsteamblog.com/windows/b/business/archive/2011/06/07/windows-thin-pc-rtms.aspx
http://virtualization.info/en/news/2011/06/release-microsoft-windows-thin-pc-1-0.html
http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/thinpc.aspx
Prenumerera på:
Inlägg (Atom)

