Een clusterimplementatie plannen en voorbereiden

  • Artikel

Het plannen en voorbereiden van een productieclusterimplementatie is erg belangrijk. Er zijn veel factoren om rekening mee te houden. In dit artikel worden de stappen beschreven voor het voorbereiden van de clusterimplementatie.

De best practices-informatie lezen

Voor het beheren van Azure Service Fabric-toepassingen en -clusters zijn er bewerkingen die u ten zeerste aanbevelen om de betrouwbaarheid van uw productieomgeving te optimaliseren. Lees de aanbevolen procedures voor Service Fabric-toepassingen en -clusters voor meer informatie.

Selecteer het besturingssysteem voor het cluster

Met Service Fabric kunt u Service Fabric-clusters maken op virtuele machines of computers waarop Windows Server of Linux wordt uitgevoerd. Voordat u uw cluster implementeert, moet u het besturingssysteem: Windows of Linux kiezen. Elk knooppunt (virtuele machine) in het cluster voert hetzelfde besturingssysteem uit. U kunt virtuele Windows- en Linux-machines niet combineren in hetzelfde cluster.

Capaciteitsplanning

Bij elke implementatie voor productie is capaciteitsplanning van groot belang. Hier volgen enkele aandachtspunten voor dat proces.

  • Het eerste aantal knooppunttypen voor uw cluster
  • De eigenschappen van elk knooppunttype (grootte, aantal exemplaren, primaire, internetgerichte, aantal VIRTUELE machines, enzovoort)
  • De betrouwbaarheid en duurzaamheid van de clusterkenmerken

Het eerste aantal knooppunttypen selecteren

Eerst moet u nagaan waarvoor het cluster waarvoor u maakt, wordt gebruikt. Welke soorten toepassingen wilt u in dit cluster implementeren? Biedt uw toepassing meerdere services en moeten hiervan een of meer service openbaar zijn of op internet gericht? Hebben uw services (waaruit uw toepassing bestaat) verschillende infrastructuurbehoeften, zoals grotere RAM- of hogere CPU-cycli? Een Service Fabric-cluster kan bestaan uit meer dan één knooppunttype: een primair knooppunttype en een of meer niet-primaire knooppunttypen. Elk knooppunttype wordt toegewezen aan een virtuele-machineschaalset. Elk knooppunttype kan dan onafhankelijk omhoog of omlaag worden geschaald, verschillende open poorten bevatten en diverse capaciteitsstatistieken hebben. Knooppunteigenschappen en plaatsingsbeperkingen kunnen worden ingesteld om specifieke services te beperken tot specifieke knooppunttypen. Zie Capaciteitsplanning voor Service Fabric-clusters voor meer informatie.

Knooppunteigenschappen selecteren voor elk knooppunttype

Knooppunttypen definiëren de VM-SKU, het aantal en de eigenschappen van de VM's in de bijbehorende schaalset.

De minimale grootte van VM's voor elk knooppunttype wordt bepaald door de duurzaamheidslaag die u kiest voor het knooppunttype. Voordat u een VM-SKU kiest, moet u de stappen begrijpen die nodig zijn voor verticaal schalen als u besluit dat u in de toekomst een andere VM-SKU nodig hebt.

Het minimale aantal VM's voor het primaire knooppunttype wordt bepaald door de betrouwbaarheidslaag die u kiest.

Zie de minimale aanbevelingen voor primaire knooppunttypen, stateful workloads op niet-primaire knooppunttypen en stateless workloads op niet-primaire knooppunttypen.

Meer dan het minimumaantal knooppunten moet zijn gebaseerd op het aantal replica's van de toepassing/services die u wilt uitvoeren in dit knooppunttype. Capaciteitsplanning voor Service Fabric-toepassingen helpt u bij het schatten van de resources die u nodig hebt om uw toepassingen uit te voeren. U kunt het cluster altijd omhoog of omlaag schalen om de toepassingsworkload te wijzigen.

Tijdelijke besturingssysteemschijven gebruiken voor virtuele-machineschaalsets

Tijdelijke besturingssysteemschijven zijn opslag die is gemaakt op de lokale virtuele machine (VM) en niet opgeslagen in externe Azure Storage. Ze worden aanbevolen voor alle Service Fabric-knooppunttypen (primair en secundair), omdat in vergelijking met traditionele permanente besturingssysteemschijven, tijdelijke besturingssysteemschijven:

  • Lees-/schrijflatentie naar besturingssysteemschijf verminderen
  • Snellere beheerbewerkingen voor opnieuw instellen/opnieuw instellen van knooppunten inschakelen
  • Totale kosten verlagen (de schijven zijn gratis en er worden geen extra opslagkosten in rekening gebracht)

Tijdelijke besturingssysteemschijven zijn geen specifieke Service Fabric-functie, maar een functie van de virtuele-machineschaalsets van Azure die zijn toegewezen aan Service Fabric-knooppunttypen. Als u deze met Service Fabric gebruikt, hebt u het volgende nodig in uw Azure Resource Manager-clustersjabloon:

  1. Zorg ervoor dat uw knooppunttypen ondersteunde Azure-VM-grootten opgeven voor tijdelijke besturingssysteemschijven en dat de VM-grootte voldoende cachegrootte heeft om de grootte van de besturingssysteemschijf te ondersteunen (zie opmerking hieronder).) Bijvoorbeeld:

    "vmNodeType1Size": {
    "type": "string",
    "defaultValue": "Standard_DS3_v2"

    Notitie

    Zorg ervoor dat u een VM-grootte selecteert met een cachegrootte die gelijk is aan of groter is dan de schijfgrootte van het besturingssysteem van de VIRTUELE machine zelf, anders kan uw Azure-implementatie een fout veroorzaken (zelfs als deze in eerste instantie wordt geaccepteerd).

  2. Geef een versie van een virtuele-machineschaalset (vmssApiVersion) van 2018-06-01 of hoger op:

    "variables": {
    "vmssApiVersion": "2018-06-01",

  3. Geef Local in de sectie virtuele-machineschaalset van uw implementatiesjabloon de optie op voor diffDiskSettings:

    "apiVersion": "[variables('vmssApiVersion')]",
"type": "Microsoft.Compute/virtualMachineScaleSets",
    "virtualMachineProfile": {
        "storageProfile": {
            "osDisk": {
                    "caching": "ReadOnly",
                    "createOption": "FromImage",
                    "diffDiskSettings": {
                        "option": "Local"
                    },
            }
        }
    }

Notitie

Gebruikerstoepassingen mogen geen afhankelijkheid/bestand/artefact op de besturingssysteemschijf hebben, omdat de besturingssysteemschijf verloren zou gaan in het geval van een upgrade van het besturingssysteem.

Notitie

Bestaande niet-tijdelijke VMSS kan niet ter plaatse worden bijgewerkt om tijdelijke schijven te gebruiken. Om te migreren, moeten gebruikers een nieuw nodeType met tijdelijke schijven toevoegen , de workloads verplaatsen naar het nieuwe nodeType en het bestaande nodeType verwijderen .

Zie Tijdelijke besturingssysteemschijven voor Azure-VM's voor meer informatie en verdere configuratieopties

De duurzaamheid en betrouwbaarheidsniveaus voor het cluster selecteren

De duurzaamheidslaag wordt gebruikt om aan te geven aan het systeem de bevoegdheden die uw VM's hebben met de onderliggende Azure-infrastructuur. Met deze bevoegdheid kan Service Fabric in het primaire knooppunttype alle infrastructuuraanvragen op VM-niveau onderbreken (zoals het opnieuw opstarten van een virtuele machine, de vm-installatiekopie of vm-migratie) die van invloed zijn op de quorumvereisten voor de systeemservices en uw stateful services. In de niet-primaire knooppunttypen kan Service Fabric infrastructuuraanvragen op VM-niveau onderbreken (zoals vm-herstart, VM-reimage en VM-migratie) die van invloed zijn op de quorumvereisten voor uw stateful services. Zie de duurzaamheidskenmerken van het cluster voor voordelen van de verschillende niveaus en aanbevelingen op welk niveau u moet gebruiken en wanneer.

De betrouwbaarheidslaag wordt gebruikt om het aantal replica's in te stellen van de systeemservices die u in dit cluster wilt uitvoeren op het primaire knooppunttype. Hoe meer replica's, hoe betrouwbaarder de systeemservices zich in uw cluster bevinden. Zie de betrouwbaarheidskenmerken van het cluster voor voordelen van de verschillende niveaus en aanbevelingen op welk niveau u moet gebruiken en wanneer.

Omgekeerde proxy en/of DNS inschakelen

Services die verbinding maken met elkaar binnen een cluster, hebben doorgaans rechtstreeks toegang tot de eindpunten van andere services, omdat de knooppunten in een cluster zich in hetzelfde lokale netwerk bevinden. Om het gemakkelijker te maken om verbinding te maken tussen services, biedt Service Fabric extra services: een DNS-service en een omgekeerde proxyservice. Beide services kunnen worden ingeschakeld bij het implementeren van een cluster.

Omdat veel services, met name in containers geplaatste services, een bestaande URL-naam kunnen hebben, kan deze worden omgezet met behulp van het standaard-DNS-protocol (in plaats van het Naming Service-protocol) is handig, met name in scenario's voor 'lift and shift'. Dit is precies wat de DNS-service doet. Hiermee kunt u DNS-namen toewijzen aan een servicenaam en daarom EINDPUNT-IP-adressen omzetten.

De services voor omgekeerde proxyadressen in het cluster die HTTP-eindpunten beschikbaar maken (inclusief HTTPS). De omgekeerde proxy vereenvoudigt het aanroepen van andere services aanzienlijk door een specifieke URI-indeling te bieden. De omgekeerde proxy verwerkt ook de stappen voor het oplossen, verbinden en opnieuw proberen die nodig zijn voor de ene service om met een andere te communiceren.

Voorbereiden op herstel na noodgeval

Een essentieel onderdeel van het leveren van hoge beschikbaarheid is ervoor te zorgen dat services alle verschillende soorten fouten kunnen overleven. Dit is vooral belangrijk voor fouten die ongepland en buiten uw controle vallen. Voorbereiden op herstel na noodgevallen beschrijft enkele veelvoorkomende foutmodi die kunnen worden gemodelleerd en correct worden beheerd. Ook worden oplossingen en acties besproken die moeten worden ondernomen als er toch een ramp is opgetreden.

Controlelijst voor productiegereedheid

Is uw toepassing en cluster klaar om productieverkeer te nemen? Voordat u uw cluster in productie implementeert, voert u de controlelijst productiegereedheid uit. Zorg ervoor dat uw toepassing en cluster soepel werken door de items in deze controlelijst te doorlopen. We raden u ten zeerste aan om al deze items af te checken voordat u in productie gaat.

Volgende stappen