Login
Menu

Microsoft Azure Stack HCI: Nytt namn och ny version av S2D

Sedan Storage Spaces introducerades i Windows Server 2012 så har Microsofts väg mot hyperkonvergerade lösningar varit något vi följt väldigt noga. Företag som VMware och Nutanix var tidigt ute men nu har Microsoft en lösning framme som på allvar kan konkurrera med dessa.
I den här artikeln reder vi ut begreppen och pekar på vad som är nytt och ser fram emot att skriva mer om våra tidigare erfarenheter av Storage Spaces Direct och nya med Azure Stack HCI.

I slutet av mars 2019 annonserade Microsoft Azure Stack HCI som i praktiken är ett nytt namn för Storage Spaces Direct (S2D) eller det bredare begreppet Windows Server Software Defined Program. Kanske är namnbytet mest marknadsföring men det signalerar ändå en hel del om hur Microsoft vill positionera sina produkter.

Jag resonerar så här:
Microsoft lanserar många nya och bra funktioner inom ramen för Windows Server och på grund av detta kanske det här med hyperkonvergerade lösningar hamnar lite i skymundan. Windows Server anses ju av många vara ett traditionellt operativsystem som i första hand används för att drifta de nödvändiga infrastrukturtjänsterna och traditionella klient-server applikationer. Inte lika många ser Windows Server som en plattform för hyperkonvergerad infrastruktur eller hybrida moln.

Hittills har Microsofts lösning på molnbaserade lösningar varit Azure Stack. Något som på papperet är kanon men i praktiken en stor och dyr apparat. Jag tror att Azure Stack tilltalar större företag med en tydligt uttalad “cloud first” eller “cloud only” strategi. Hoppet från traditionell Hyper-V till Azure Stack innebär också en stor förändring eftersom Azure Stack innebär konsumtion av tjänster enligt de principer vi känner igen från publika moln. Det är här Azure Stack HCI kommer in och fyller tomrummet mellan Hyper-V och Azure Stack.

Förutom att vara en mjukvarudefinierad lagringslösning för Windows Server så är Azure Stack HCI mer av en nyckelfärdig lösning för hyperkonvergerad infrastruktur med en ansenlig mängd funktioner för hybrida moln. Fokuset är på traditionella virtuella maskiner och inte applikationer och tjänster som generellt återfinns i publika moln byggda på Azure Stack.

Azure Stack HCI låter dig köra virtuella maskiner on-premise ovanpå en infrastruktur som består av Windows Server, Hyper-V, Storage Spaces Direct och hanteras i nya Windows Admin Center.

Du köper hårdvaran i form av godkända konfigurationer från certifierade tillverkare, t.ex. Dell, HPE, Supermicro m.fl. Förutom godkända konfigurationer skall detta också innebära support på hela lösningen (alltså hw + sw) från en och samma kontakt, tillverkaren i det här fallet.
Det här är en av de stora skillnaderna med Azure Stack och Azure Stack HCI, i fallet med HCI är konfigurationen av hårdvaran mer flexibel och du får ändra på den. Medans Azure Stack kommer i mindre dynamiska block. Du har också tillgång och kontroll över de underliggande komponenterna Windows Server, Hyper-V och S2D, vilket du inte har i Azure Stack.

Om vi lyfter blicken ovanför infrastrukturen och tittar på tjänsterna så skiljer sig Azure Stack och Azure Stack HCI väsentligt. Azure Stack HCI erbjuder inte samma möjligheter att driftsätta applikationer och tjänster on-premise på samma sätt som Azure Stack. I stället erbjuder Azure Stack HCI integrationer med Azure i form av:

• Azure Site Recovery for high availability and disaster recovery as a service (DRaaS).
• Azure Monitor, a centralized hub to track what’s happening across your applications, network, and infrastructure – with advanced analytics powered by AI.
• Cloud Witness, to use Azure as the lightweight tie breaker for cluster quorum.
• Azure Backup for offsite data protection and to protect against ransomware.
• Azure Update Management for update assessment and update deployments for Windows VMs running in Azure and on-premises.
• Azure Network Adapter to connect resources on-premises with your VMs in Azure via a point-to-site VPN.
• Azure Security Center for threat detection and monitoring for VMs running in Azure and on-premises (coming soon).
Nyheter inom Storage Spaces Direct för Windows Server 2019 är följande, vilket vi då också återspeglas i Azure Stack HCI:
• Deduplication and compression for ReFS volumes
• Native support for persistent memory
• Nested resiliency for two-node hyper-converged infrastructure at the edge
• Two-server clusters using a USB flash drive as a witness
• Performance history
• Scale up to 4 PB per cluster
• Mirror-accelerated parity is 2X faster
• Drive latency outlier detection
• Manually delimit the allocation of volumes to increase fault tolerance

De nyheter vi tycker är mest spännande är deduplicering och komprimering för ReFS samt två noders kluster. Båda dessa funktioner bidrar till lägre investeringskostnader. Att kunna bygga ett cluster med bara två noder passar mindre företag som har en stor andel traditionella applikationer och virtuella maskiner perfekt. Prisbilden blir riktigt intressant samtidigt som prestandan brukar räcka till med marginal.

Sammanfattningsvis tycker vi att det är kanon att Microsoft numera har en paketerad lösning för hyperkonvergerade infrastruktur. Dessutom kan vi lita på att hårdvarutillverkarna har gjort en del av arbetet och tar ansvar för att komponenterna skall lira ihop.
Men framförallt är detta en lösning där vi kan få riktigt grym prestanda och kapacitet till ett lågt pris i vårt lokala datacenter och sedan nyttja Azure för backup och katastrofsäkring.

Cryptolockers i Sverige 2019

För några år sedan ringde det ibland kunder och hade den där speciella tonen på rösten som hintar om att något allvarligt har hänt. På den tiden förutsatte vi nästan att orsaken berodde på en cryptolocker av något slag.

Majoriteten av de kunder som drabbades kunde vi snabbt hjälpa genom att återställa data från snapshots. I resten av fallen fick vi återställa från backuper eller kanske replikerat data. Men vi hade aldrig en kund som drabbades av en dataförlust och tvingades betala lösensumman.
Nu har tiden gått och samtalen angående cryptolockers har minskat rejält. Både säkerhetsprodukterna och vi människor har anpassat oss till det hotet.

Häromdagen fick vi ändå ett nytt samtal gällande cryptolockers och denna gång var det illa, riktigt illa. Kunden i fråga hade upptäckt att ett konto var inloggat på servrarna som inte ska vara inloggat, samt att alla filer var konstiga, alltså krypterade.
I det här fallet fanns inga SAN snapshots. Replikering av virtuella maskiner då? Ja, men de servrar som var drabbade hade inte klassificerats och konfigurerats för replikering. Men det är ju lugnt, alla har ju backup? Ja visst, men olyckligtvis hade backupservern en utdelad katalog via vilken smittan spred sig. Det ledde till att backuperna var obrukbara.
Efter en hel del arbete stod vi inför faktum att enda utvägen var att betala den begärda lösensumman för att få backupservern återställd och därefter kunna återställa data från övriga servrar som drabbats.

Med anledning av den senaste upplevelsen där allt sket sig har jag sammanfattat ett par lärdomar som jag vill dela med mig av. Vissa saker är kanske självklarheter för somliga men jag hoppas att alla hittar något nytt:

  • Låt inte någon server vara exponerad på internet via RDP och se verkligen till att du inte använder dåliga lösenord. I dag verkar den vanligaste attackvektorn för cryptolockers vara just brute force attacker mot kända konton via RDP.
  • Om du har möjlighet inaktivera SMB1 protokollet och inventera dina utdelade mappar. Behöver du verkligen ha det där restore$ sharet på backup-servern tillgängligt hela tiden?
  • Överväg om din backupserver verkligen ska vara medlem i ditt AD. Detta för att undvika att ett kompromissat konto kan manipulera din backupserver. Det finns andra goda effekter av detta också som att din backupserver kanske är lite gladare även om hela ditt AD är nere.
  • Utnyttja snapshotteknik om du har det i ditt lagringssystem, detta är en oerhört effektiv metod för att snabbt kunna återställa stora datamängder. För hur snabbt går det egentligen för dig att återställa 10 servrar från backup? Har du inte tillgång till snapshotteknik kanske du ska byta lagringssystem?
  • Om du replikerar data eller virtuella maskiner mellan flera datacenter så fundera igenom vilka maskiner som omfattas av detta. Normalt sett väljer man kanske bara det som verkligen är affärskritiskt eftersom en sekundär site driver kostnader utan att generera någon direkt nytta. En stor fördel med replikerade virtuella maskiner är att dess kopior är avstängda och bortkopplade från nätverket. Vilket är ett av de bästa skydden mot smittor. Så även om du inte anpassar din sekundära site för att kunna köra alla system bör du överväga att kunna lagra en kopia av allt data.

VMware Update Manager ESXi Upgrade Incompatible

När ESXi servrar skall uppdateras från en version till en annan är det väldigt smidigt att använda Update Manager. Det är enkelt att ladda hem en ny så kallade Custom ISO från hårdvarutillverkaren för den nya versionen och med hjälp av en Upgrade Baseline i Update Manager genomföra uppgraderingen.
Men många gånger stöter man på problem. Vi har stött på många olika orsaker så som för små partitioner för ESXi, bootbank state kataloger som inte är tomma, konflikter med VIB:ar som inte stöds av den nya versioner etcetera.
Just VIB konflikter kanske är en av de vanligare orsakerna. Nyligen utförde vi en vSphere 6.0 till vSphere 6.7 uppgradering. I den aktuella miljön körs det Dell PowerEdge R630 servrar och vi använde Dells senaste Custom ISO för ESXi 6.7 U2 för att genomföra uppgraderingen.
Inför uppgraderingen flaggades servrarna som “Incompatible” av Update Manager. Från resultatet av “Scan Entity” framgick följande

“The upgrade has VIBs that are missing dependencies. Remove the VIBs or use Image Builder to create a custom upgrade ISO image that contains the missing dependencies, and try to upgrade again.”

Tyvärr framgick inga ytterligare detaljer om vilken VIB som saknade beroenden. Men genom att gå igenom loggfiler /var/log/vua.log och leta efter texten “MISSING_DEPENDENCY_VIBS” kunde vi identifiera vad som orsakade detta.

–>     <test>

–>       <name>MISSING_DEPENDENCY_VIBS</name>

–>       <expected>

–>

–>       </expected>

–>       <found>

–>         <value>VMware_bootbank_scsi-qla2xxx_902.k1.1-9vmw.510.0.0.799733</value>

–>       </found>

–>       <result>ERROR</result>

–>     </test>

Vi avinstallerade scsi-qla2xxx och startade om ESXi servern

[root@esx07:/var/log] esxcli software vib remove -n scsi-qla2xxx

Removal Result

   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

   Reboot Required: true

   VIBs Installed:

   VIBs Removed: VMware_bootbank_scsi-qla2xxx_902.k1.1-9vmw.510.0.0.799733

   VIBs Skipped:

Efter omstart körde vi en ny Scan på ESXi servern och status för uppgraderingen ändrades från Incompatible till “Non-Compliant” så nu gick det bra att köra igenom uppgraderingen.

Slutsatsen är alltså att /var/log/vua.log är en mycket bra plats för att få ytterligare information om varför olika åtgärder som utförs av Update Manager strular.

Genom att fylla i dina uppgifter nedan anmäler du dig till Pareras nyhetsbrev. Vi kommer inte att lämna ut dina uppgifter till någon annan part och du har alltid möjligheten att avanmäla dig från nyhetsbrevet när du själv vill.