Onderwijs en informatietechnologie (IT) zijn steeds meer onlosmakelijk met elkaar verbonden. Of de IT in kwestie een applicatie is die een whiteboard in een klaslokaal ondersteunt, de database die een universiteitsregistratiesysteem ondersteunt, de leerbeheersystemen (LMS) of het gebouwonderhoudssysteem dat de toegang van studenten tot de laboratoria, slaapzalen en eetzalen controleert – als de belangrijkste componenten van uw IT-infrastructuur plotseling uitvalt, kunnen noch docenten, beheerders, noch studenten bereiken wat ze moeten bereiken. De missie van de instelling wordt onderbroken. Als de onderbrekingen te vaak voorkomen, als de ervaringen van studenten, docenten en bestuurders eronder lijden, kan de reputatie van de instelling zelf ook lijden.
Een IT-infrastructuur die is ontworpen om de hoge beschikbaarheid (HA) te garanderen van applicaties die cruciaal zijn voor de onderwijservaring, kan het risico op verstoring en reputatieverlies minimaliseren dat zou kunnen optreden als deze systemen om welke reden dan ook niet meer reageren. In dit geval wordt een HA-infrastructuur gedefinieerd als een infrastructuur die in staat is om de beschikbaarheid van belangrijke applicaties niet minder dan 99,99% van de tijd te garanderen. Anders gezegd betekent dit dat uw kritische applicaties niet onverwacht langer dan vier minuten per maand offline zullen zijn.
Hoe bereik je HA? Die vraag is gemakkelijk te beantwoorden, maar het is niet de enige vraag die u moet stellen. Net zo belangrijk is dit: welke applicaties zijn zo kritisch dat ze een HA-configuratie rechtvaardigen? De kern van een IT-infrastructuur die is geconfigureerd voor HA bestaat uit een of meer sets secundaire servers en opslagsubsystemen die zich op een geografisch verschillende locatie bevinden (wat een extern datacenter kan zijn als uw primaire server zich op locatie bevindt of op een afzonderlijke beschikbaarheidslocatie). zone [AZ] als uw servers zich in de cloud bevinden). Als iets ervoor zorgt dat de applicaties die op de primaire server draaien niet meer reageren, zal de HA-software die uw applicatie beheert onmiddellijk een failover uitvoeren naar de secundaire server, waar uw kritieke applicaties opnieuw opstarten vanaf het punt waarop de primaire server niet meer reageerde. Afhankelijk van de grootte en prestatiekenmerken van de primaire server die u wilt repliceren, kan die secundaire server kostbaar zijn, dus het is onwaarschijnlijk dat u al uw academische applicaties voor HA gaat configureren . Zodra u heeft bepaald welke applicaties de investering in HA rechtvaardigen, weet u waar u een HA-omgeving moet uitbouwen.
Keuzes voor het bereiken van hoge beschikbaarheid
Zodra u de toepassingen heeft gekozen die u wilt beschermen, worden uw opties voor het bereiken van HA duidelijker. Draaien ze op Windows of Linux? Heeft uw databasebeheersysteem (DBMS) ingebouwde ondersteuning voor een HA-configuratie? Zo ja, wat zijn de beperkingen ervan? Als uw kritieke applicaties bijvoorbeeld op Windows en SQL Server draaien, kunt u HA inschakelen met behulp van de Availability Group (AG)-functie van SQL Server zelf. Als alternatief kunt u HA configureren met behulp van een SANless clusteringtool van derden, die opties biedt die de AG-services in SQL Server niet bieden. Als u databaseservers van meerdere leveranciers probeert te beschermen, of als sommige van uw kritieke applicaties op Windows draaien terwijl andere op Linux draaien, wordt uw vermogen om HA te beheren vergemakkelijkt door het gebruik van een HA-oplossing die meerdere DBMS en besturingssystemen ondersteunt. platforms. Kiezen voor een clusteroplossing die verschillende DBMS- en OS-platforms herbergt, vereenvoudigt het beheer, in tegenstelling tot de potentiële complexiteit en omslachtigheid van het gelijktijdig verwerken van meerdere database-native HA-services.
Zorgen voor hoge beschikbaarheid via database-native HA-oplossingen
Als u een database-native HA-oplossing gebruikt, zoals de AG-functie van SQL Server, repliceert de software alle gegevens in uw primaire SQL Server-database synchroon naar een identiek exemplaar van die database op de secundaire systeemserver. Als iets ervoor zorgt dat de primaire server niet meer reageert, zullen de monitoringfuncties in de AG-component er automatisch voor zorgen dat de secundaire server het overneemt. Omdat de AG-functie alle gegevens in realtime heeft gerepliceerd, kan de secundaire server het onmiddellijk overnemen en is er vrijwel geen onderbreking van de service of verlies van gegevens.
Veel database-native HA-tools werken op een vergelijkbare manier. Er zijn echter enkele kanttekeningen bij het overwegen van een database-native benadering: als de HA-services in het DBMS zelf zijn gebundeld, kunnen ze alleen de gegevens repliceren die aan dat DBMS zijn gekoppeld. Als zich andere kritieke gegevens op uw primaire server bevinden, worden deze niet gerepliceerd naar de secundaire server in een database-native HA-scenario. Er kunnen ook andere beperkingen zijn voor wat de database-native services zullen repliceren. Als u bijvoorbeeld de Basic AG-functionaliteit gebruikt die is gebundeld in SQL Server Standard Edition, kan elke AG slechts één SQL-database repliceren naar één secundaire locatie. U kunt meerdere Basic AG’s maken als uw toepassingen meerdere SQL-databases omvatten, maar u kunt niet bepalen of elke AG tegelijkertijd een failover uitvoert in een failover-situatie. Als dat niet het geval is, kunnen er problemen ontstaan. Een manier om deze beperking te omzeilen zou zijn om de Always On AG-functionaliteit te gebruiken die is gebundeld in SQL Server Enterprise Edition, waarmee de replicatie van meerdere SQL-databases naar meerdere secundaire servers mogelijk is, maar dat kan vanuit licentieperspectief erg duur worden als uw applicaties dat niet doen. gebruik anders een van de functies van SQL Server Enterprise Edition.
Andere database-native HA-oplossingen kunnen vergelijkbare beperkingen hebben, dus zorg ervoor dat u deze begrijpt voordat u in een dergelijke aanpak investeert.
Garanderen van hoge beschikbaarheid via SANless Clustering
Als alternatief voor de database-native benadering van HA kunt u een tool van derden gebruiken om een SAN-loos cluster te maken. Net als in de hierboven beschreven AG-configuratie automatiseert de SANless clusteringsoftware de synchrone replicatie van gegevens van de primaire naar de secundaire server; het orkestreert ook de onmiddellijke failover naar de secundaire server als de primaire server niet meer reageert. Omdat de failover slechts enkele seconden duurt, blijft de toegang van beheerders, docenten en studenten tot uw kritieke applicaties vrijwel ononderbroken.
De cruciale verschillen tussen SANless clustering en een database-native aanpak liggen in de praktische details. De SANless-clusteringbenadering is database-agnostisch. Het repliceert alle gegevens op een aangewezen opslagvolume. Dat kunnen meerdere databases van meerdere leveranciers zijn, tekstbestanden, videobestanden of enig ander educatief materiaal waarvan de beschikbaarheid belangrijk is. Dit kan een instelling een aanzienlijke hoeveelheid geld besparen als een database-native benadering van HA anders een upgrade naar een duurdere editie van de database zou vereisen. Tot slot, zoals eerder opgemerkt: als u applicaties en gegevens probeert te beschermen die in meerdere besturingsomgevingen draaien, kan een SAN-loze clusteringbenadering beter beheersbaar zijn dan individuele database-native benaderingen. U kunt SANless clustering gebruiken om HA te garanderen in zowel Windows- als Linux-omgevingen, waardoor de complexiteit kan worden geëlimineerd die gepaard zou kunnen gaan met de implementatie van database-native benaderingen die per besturingsomgeving verschillen.