Budapest Sysadmin Meetup 2016.09.21. Failover Cluster 1x1 Gál Tamás v-tgal@microsoft.com Cloud Infrastructure TSP Microsoft Magyarország
Windows Server Failover Cluster Magas rendelkezésre állás Megengedhető kiesés / év 99% 99,9% 99,99% 99,999% 3 nap 15 óra 36 perc 8 óra 45 perc 36 mp. 52 perc 33 mp. 5 perc 15 mp.
Szolgáltatás többszörözése Virtualizációs réteg alkalmazása Fürtözés
Failover Cluster Magas rendelkezésre állás Hardver HA
Fizikai szerver https://www.windowsservercatalog.com/ UCS B200 M3! Console Reset UCS B200 M3! Console Reset UCS B200 M3! Console Reset
Támogatott tárolási megoldások iscsi SAS Serial Attached SCSI FCoE Fiber Channel over Ethernet SMB v3.x A WS12 óta Fiber Channel (FC) shared *.vhdx A WS12R2 óta Storage Spaces
MEMORY Modified Configuration Memory memory content data pages IP connection iscsi, FC or SMB Storage
Configuration State
Scale up... Scale out...
Stabilabb OS Kisebb támadási felület A WS12 óta van járható, oda-vissza út a Server Core és full UI között, újratelepítés nélkül is.
Szavazási modell a vállalható működés biztosítására Lehetséges szavazók: a fürttagok (mindegyik) + 1 tanúlemez (lemez vagy fájlmegosztás) Korábban 3-4 quorum típus, a WS12R2 óta dinamikus (az aktuális fürttagságtól függ, mindig páratlan) Teljesen automatikus működés De meg is tudjuk nézni, hogy áll: (Get- Cluster).WitnessDynamicWeight Cluster Dynamic Quorum Configuration
Integrált frissítési megoldás a fürtök számára Az új frissítéseket észleli és a szerverterheléseket az adott tagról egy másikra terheli a frissítés idejére Kevesebb szerverleállás a fürt tagok frissítésének koordinálásával Teljesen automatizálható, nincs emberi tényező Windows Update Agent és / vagy külső bővítmények segítségével működik Kétfajta üzemmód: helyi és távoli U Current Workload Third-party plug-in for updates Application Client Windows Server Cluster
A fontosabb virtuális gépek költözés esetén mindenképpen elindulnak Ha nincs elég erőforrás, akkor az alacsonyabb prioritású gépek automatikusan leállnak vagy mentett állapotba kerülnek A lekapcsolt gépeket a rendszer ciklikusan megpróbálja ismételten elindítani Node hiba! Nincs elég memória! Sikeres VM indítás Az alacsonyabb prioritású virtuális gépek leállíthatóak
Alkalmazások ellenőrzése - a VM-eken belül Bármilyen rendszerszolgáltatást lehetséges monitorozni (WS, SQL, Exchange, stb. is), a VM-en kívülről Ha megáll, egy szolgáltatás újraindítás következik 3 egymás utáni hiba után a cluster egy bejegyzést tesz az eseménynaplóba (ID 1250) VM állapota Application Critical -ra változik és újra is indulhat automatikusan Ha nincs változás, egy másik tagra költözik és ott indul újra Windows Server 2012 és R2 lehet a VM
Optimális VM elhelyezés Upon Hyper-V Anti-Affinity failover, cluster VMs keeps with restart related VMs in on priority VMs each apart node order Az affinitiás szabályai szerint a VMek kétféle jellemzővel bírhatnak: Preferált tulajdonos Lehetséges tulajdonos Az AntiAffinityClassNames tulajdonság alapján viszont az adott virtuális gépek nem futhatnak azonos fürttagon Konfigurálható: Powershell vagy SCVMM
A virtuális gépek automatikusan átkerülnek leálláskor egy másik fürttagra, azaz a legjobb fürttagra Legjobb = a legtöbb szabad RAM-ot birtokló A VM priorizáció figyelembevételével Konfigurálható > (Get-Cluster).DrainOnShutdown Az alapértelmezett érték az 1-es, tehát a drain mód Ajánlás Továbbra is célszerű a fürttagok megjelölése újraindítás/leállítás előtt
Detektálás az adott virtuális gép szintjén Health Monitoring A virtuális gépekben hálózatonként konfigurálható Recovery Hálózatvesztés esetén > live migration De először ellenőrzi a célhelyen az adott hálózatot Live migration
ServerA ServerB Server1 ServerC Replica broker Server2 Server3 Hibatűrő fürt 1 Hibatűrő fürt 2
Budapest Sysadmin Meetup 2016.09.21. Failover Cluster 1x1 Gál Tamás v-tgal@microsoft.com Cloud Infrastructure TSP Microsoft Magyarország