Share via

Herstel na noodgeval instellen voor een IIS-webtoepassing met meerdere lagen

  • Artikel

Toepassingssoftware is de engine van bedrijfsproductiviteit in een organisatie. Verschillende webtoepassingen kunnen verschillende doeleinden in een organisatie dienen. Sommige toepassingen, zoals toepassingen die worden gebruikt voor de verwerking van salarisadministratie, financiële toepassingen en klantgerichte websites, zijn mogelijk essentieel voor een organisatie. Om verlies van productiviteit te voorkomen, is het belangrijk dat de organisatie deze toepassingen continu laat werken. Belangrijker is dat het consistent beschikbaar maken van deze toepassingen kan helpen bij het voorkomen van schade aan het merk of de afbeelding van de organisatie.

Kritieke webtoepassingen worden doorgaans ingesteld als toepassingen met meerdere lagen: het web, de database en de toepassing bevinden zich op verschillende lagen. Naast de verdeling over verschillende lagen, kunnen de toepassingen ook meerdere servers in elke laag gebruiken om het verkeer te verdelen. Bovendien zijn de toewijzingen tussen verschillende lagen en op de webserver mogelijk gebaseerd op statische IP-adressen. Bij failover moeten sommige van deze toewijzingen worden bijgewerkt, met name als er meerdere websites zijn geconfigureerd op de webserver. Als webtoepassingen TLS gebruiken, moet u certificaatbindingen bijwerken.

Traditionele herstelmethoden die niet zijn gebaseerd op replicatie, omvatten het maken van back-ups van verschillende configuratiebestanden, registerinstellingen, bindingen, aangepaste onderdelen (COM of .NET), inhoud en certificaten. Bestanden worden hersteld via een reeks handmatige stappen. De traditionele herstelmethoden voor het maken van back-ups en het handmatig herstellen van bestanden zijn omslachtig, foutgevoelig en niet schaalbaar. U kunt bijvoorbeeld eenvoudig vergeten een back-up te maken van certificaten. Na een failover hoeft u geen nieuwe certificaten voor de server te kopen.

Een goede oplossing voor herstel na noodgevallen biedt ondersteuning voor het modelleren van herstelplannen voor complexe toepassingsarchitecturen. U moet ook aangepaste stappen aan het herstelplan kunnen toevoegen om toepassingstoewijzingen tussen lagen te verwerken. Als er zich een noodgeval voordoet, bieden toepassingstoewijzingen één klik, een oplossing die zeker kan worden gemaakt, waardoor een lagere RTO ontstaat.

In dit artikel wordt beschreven hoe u een webtoepassing beveiligt die is gebaseerd op IIS (Internet Information Services) met behulp van Azure Site Recovery. In het artikel worden aanbevolen procedures beschreven voor het repliceren van een webtoepassing met drie lagen naar Azure, het uitvoeren van een noodherstelanalyse en het uitvoeren van een failover van de toepassing naar Azure.

Vereisten

Voordat u begint, moet u ervoor zorgen dat u weet hoe u de volgende taken moet uitvoeren:

Implementatiepatronen

Een webtoepassing op basis van IIS volgt doorgaans een van de volgende implementatiepatronen:

Implementatiepatroon 1

Een webfarm op basis van IIS met ARR (Application Request Routing), een IIS-server en SQL Server.

Diagram of an IIS-based web farm that has three tiers

Implementatiepatroon 2

Een webfarm op basis van IIS met ARR, een IIS-server, een toepassingsserver en SQL Server.

Diagram of an IIS-based web farm that has four tiers

Ondersteuning voor Site Recovery

Voor de voorbeelden in dit artikel gebruiken we virtuele VMware-machines met IIS 7.5 op Windows Server 2012 R2 Enterprise. Omdat Site Recovery-replicatie niet toepassingsspecifiek is, worden de aanbevelingen in dit artikel naar verwachting toegepast in de scenario's die worden vermeld in de volgende tabel en voor verschillende versies van IIS.

Bron en doel

Scenario Op een secundaire site In Azure
Hyper-V Ja Ja
VMware Ja Ja
Fysieke server Nr. Ja
Azure N.v.t. Ja

Virtuele machines repliceren

Als u wilt beginnen met het repliceren van alle virtuele IIS-webfarmmachines naar Azure, volgt u de richtlijnen in Testfailover naar Azure in Site Recovery.

Als u een statisch IP-adres gebruikt, kunt u het IP-adres opgeven dat u wilt gebruiken voor de virtuele machine. Als u het IP-adres wilt instellen, gaat u naar HET DOEL-IP-adres van de netwerkinstellingen>.

Screenshot that shows how to set the target IP in the Site Recovery Network pane

Een herstelplan maken

Een herstelplan ondersteunt het sequentiëren van verschillende lagen in een toepassing met meerdere lagen tijdens een failover. Met sequentiëren kunt u toepassingsconsistentie behouden. Wanneer u een herstelplan voor een webtoepassing met meerdere lagen maakt, voert u de stappen uit die worden beschreven in Een herstelplan maken met behulp van Site Recovery.

Virtuele machines toevoegen aan failovergroepen

Een typische IIS-webtoepassing met meerdere lagen bestaat uit de volgende onderdelen:

  • Een databaselaag met virtuele SQL-machines.
  • De weblaag, die bestaat uit een IIS-server en een toepassingslaag.

Virtuele machines toevoegen aan verschillende groepen op basis van de laag:

  1. Maak een herstelplan. Voeg de virtuele machines in de databaselaag toe onder Groep 1. Dit zorgt ervoor dat virtuele machines in de databaselaag voor het laatst worden afgesloten en eerst worden opgehaald.
  2. Voeg de virtuele machines in de toepassingslaag toe onder Groep 2. Dit zorgt ervoor dat virtuele machines op de toepassingslaag worden weergegeven nadat de databaselaag is opgehaald.
  3. Voeg de virtuele machines in de weblaag toe in groep 3. Dit zorgt ervoor dat virtuele machines op de weblaag worden weergegeven nadat de toepassingslaag is opgehaald.
  4. Voeg taakverdeling toe aan virtuele machines in groep 4. Dit zorgt ervoor dat de taakverdeling van virtuele machines wordt weergegeven nadat de weblaag is opgestart.

Zie Het herstelplan aanpassen voor meer informatie.

Een script toevoegen aan het herstelplan

Om de IIS-webfarm correct te laten functioneren, moet u mogelijk enkele bewerkingen uitvoeren op de virtuele Azure-machines na een failover of tijdens een testfailover. U kunt enkele bewerkingen na failover automatiseren. U kunt bijvoorbeeld de DNS-vermelding bijwerken, een sitebinding wijzigen of een verbindingsreeks wijzigen door bijbehorende scripts toe te voegen aan het herstelplan. Als u een VMM-script toevoegt aan een herstelplan , wordt beschreven hoe u geautomatiseerde taken instelt met behulp van een script.

DNS-update

Als DNS is geconfigureerd voor dynamische DNS-update, worden de DNS-machines meestal bijgewerkt met het nieuwe IP-adres wanneer ze worden gestart. Als u een expliciete stap wilt toevoegen om DNS bij te werken met de nieuwe IP-adressen van de virtuele machines, voegt u een script toe om HET IP-adres in DNS bij te werken als een actie na failover voor herstelplangroepen.

Verbinding maken iontekenreeks in web.config van een toepassing

De verbindingsreeks geeft de database aan waarmee de website communiceert. Als de verbindingsreeks de naam van de virtuele databasemachine bevat, zijn er geen verdere stappen nodig na de failover. De toepassing kan automatisch communiceren met de database. Als het IP-adres voor de virtuele databasemachine wordt bewaard, hoeft u de verbindingsreeks niet bij te werken.

Als de verbindingsreeks verwijst naar de virtuele databasemachine met behulp van een IP-adres, moet deze na de failover worden bijgewerkt. De volgende verbindingsreeks verwijst bijvoorbeeld naar de database met het IP-adres 127.0.1.2:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add name="ConnStringDb1" connectionString="Data Source= 127.0.1.2\SqlExpress; Initial Catalog=TestDB1;Integrated Security=False;" />
</connectionStrings>
</configuration>

Als u de verbindingsreeks in de weblaag wilt bijwerken, voegt u een IIS-verbindingsupdatescript toe na groep 3 in het herstelplan.

Sitebindingen voor de toepassing

Elke site bestaat uit bindingsinformatie. De bindingsinformatie bevat het type binding, het IP-adres waarop de IIS-server luistert naar de aanvragen voor de site, het poortnummer en de hostnamen voor de site. Tijdens de failover moet u deze bindingen mogelijk bijwerken als er een wijziging is in het IP-adres dat eraan is gekoppeld.

Notitie

Als u de sitebinding instelt op Alle niet-toegewezen, hoeft u deze binding niet bij te werken na een failover. Als het IP-adres dat is gekoppeld aan een site niet wordt gewijzigd na een failover, hoeft u de sitebinding niet bij te werken. (De retentie van het IP-adres is afhankelijk van de netwerkarchitectuur en subnetten die zijn toegewezen aan de primaire en herstelsites. Het is mogelijk dat het niet haalbaar is om ze bij te werken voor uw organisatie.)

Screenshot that shows setting the TLS/SSL binding

Als u het IP-adres aan een site hebt gekoppeld, werkt u alle sitebindingen bij met het nieuwe IP-adres. Als u de sitebindingen wilt wijzigen, voegt u een updatescript voor de IIS-weblaag toe na groep 3 in het herstelplan.

Het IP-adres van de load balancer bijwerken

Als u een virtuele ARR-machine hebt, voegt u na groep 4 een IIS ARR-failoverscript toe om het IP-adres bij te werken.

TLS/SSL-certificaatbinding voor een HTTPS-verbinding

Een website heeft mogelijk een gekoppeld TLS/SSL-certificaat dat zorgt voor een veilige communicatie tussen de webserver en de browser van de gebruiker. Als de website een HTTPS-verbinding heeft en ook een gekoppelde HTTPS-sitebinding heeft met het IP-adres van de IIS-server met een TLS/SSL-certificaatbinding, moet u een nieuwe sitebinding voor het certificaat toevoegen met het IP-adres van de virtuele IIS-machine na een failover.

Het TLS/SSL-certificaat kan worden uitgegeven op basis van deze onderdelen:

  • De volledig gekwalificeerde domeinnaam van de website.
  • De naam van de server.
  • Een jokertekencertificaat voor de domeinnaam.
  • Een IP-adres. Als het TLS/SSL-certificaat wordt uitgegeven op basis van het IP-adres van de IIS-server, moet er een ander TLS/SSL-certificaat worden uitgegeven op basis van het IP-adres van de IIS-server op de Azure-site. Er moet een extra TLS-binding voor dit certificaat worden gemaakt. Daarom raden we u aan geen TLS/SSL-certificaat te gebruiken dat is uitgegeven op basis van het IP-adres. Deze optie wordt minder algemeen gebruikt en wordt binnenkort afgeschaft in overeenstemming met nieuwe wijzigingen in het forum van de certificeringsinstantie/browser.

De afhankelijkheid tussen de weblaag en de toepassingslaag bijwerken

Als u een toepassingsspecifieke afhankelijkheid hebt die is gebaseerd op het IP-adres van de virtuele machines, moet u deze afhankelijkheid na failover bijwerken.

Een testfailover uitvoeren

  1. Selecteer uw Recovery Services-kluis in Azure Portal.
  2. Selecteer het herstelplan dat u hebt gemaakt voor de IIS-webfarm.
  3. Selecteer Failover testen.
  4. Als u het testfailoverproces wilt starten, selecteert u het herstelpunt en het virtuele Azure-netwerk.
  5. Wanneer de secundaire omgeving is ingeschakeld, kunt u validaties uitvoeren.
  6. Wanneer de validaties zijn voltooid, selecteert u Validaties voltooid om de testfailoveromgeving op te schonen.

Zie Testfailover naar Azure in Site Recovery voor meer informatie.

Een failover uitvoeren

  1. Selecteer uw Recovery Services-kluis in Azure Portal.
  2. Selecteer het herstelplan dat u hebt gemaakt voor de IIS-webfarm.
  3. Selecteer Failover.
  4. Selecteer het herstelpunt om het failoverproces te starten.

Zie Failover in Site Recovery voor meer informatie.

Volgende stappen