Välja rätt storlek och intervall för undernätet för Azure SQL Managed Instance

  • Artikel

Gäller för:Azure SQL Managed Instance

Den här artikeln hjälper dig att fastställa lämplig undernätsstorlek och IP-adressintervall för Azure SQL Managed Instance.

Översikt

Azure SQL Managed Instance består av tjänstkomponenter som finns på en dedikerad uppsättning isolerade virtuella datorer placerade i en eller flera virtuella datorgrupper som hanteras av ett virtuellt kluster och distribueras i ett virtuellt Azure-nätverk.

Ett virtuellt kluster som är associerat med ett enda undernät i ett virtuellt nätverk kan vara värd för en eller flera SQL-hanterade instanser. Antalet instanser som kan distribueras till ett undernät beror på storleken på undernätet (undernätsintervallet).

När du skapar en SQL-hanterad instans allokerar Azure ett antal virtuella datorer baserat på den valda tjänstnivån. Eftersom dessa virtuella datorer är associerade med ditt undernät kräver de IP-adresser. För att säkerställa hög tillgänglighet under regelbunden drift och serviceunderhåll kan Azure allokera ytterligare virtuella datorer. Antalet nödvändiga IP-adresser i ett undernät är vanligtvis större än antalet SQL-hanterade instanser i undernätet.

Fastställa undernätsstorlek

Planera noggrant undernätsstorleken för dina SQL-hanterade instansdistributioner.

Varje SQL-hanterad instans behöver avsiktligt minst 32 IP-adresser i ett undernät. Du kan använda en minsta nätmask på /27 när du definierar undernätets IP-intervall.

Följande är en lista över överväganden när du bestämmer storleken på ditt undernät:

  • Instansrelaterade överväganden:
    • Antal SQL-hanterade instanser
    • Tjänstnivå för instanser
  • Överväganden relaterade till virtuella kluster:
    • Maskinvarukonfigurationer
    • Konfigurationer av underhållsfönster
  • Överväganden relaterade till hanteringsåtgärder:
    • Planer på att skala upp/ned eller ändra tjänstnivå, maskinvarukonfiguration eller underhållsperiod

Använd följande parametrar för att skapa en beräkning:

  • Azure använder fem IP-adresser i undernätet för sina egna behov.
  • Varje virtuell datorgrupp allokerar ytterligare sex adresser.
  • Varje SQL-hanterad instans använder ett antal adresser som är beroende av tjänstnivån.
    • Sql-hanterad instans för generell användning använder tre adresser
    • Affärskritisk SQL-hanterad instans använder fem adresser
  • Varje skalningsbegäran fördubblar tillfälligt antalet adresser som allokerats för den instans som skalas

Viktigt!

Eftersom det inte går att ändra adressintervallet för undernätet när resurser finns i undernätet är det bättre att använda större undernät i stället för mindre för att förhindra problem i framtiden.

En enda distribuerad instans

I följande tabell visas antalet IP-adresser som krävs för en enskild instans i ett undernät som distribueras till varje tjänstnivå:

Tjänstenivå Azure-användning1 Användning avVM-grupp 2 Instansanvändning Totalt3
Generell användning 5 6 3 14
Affärskritisk 5 6 5 16

1 Adresser som används av Azure delas mellan alla instanser i undernätet
2 Adresser som används av vm-gruppen delas mellan instanser som placeras i samma grupp
3 Det totala antalet adresser som används av instansen

Om du lägger till instanser i undernätet ökar antalet adresser som används av instansen och ökar därför det totala antalet adresser.

Undernät för flera instanser

Formeln i det här avsnittet beräknar antalet adresser som krävs för flera instanser i ett undernät, med hänsyn till möjligheten att skapa en ny virtuell datorgrupp under en efterföljande instans skapa eller uppdatera begäran, samt underhållsfönstret och maskinvarukraven för virtuella kluster.

Använd följande formel för att beräkna det totala antalet IP-adresser baserat på antalet instanser:

5 + (a * 6) + (b * 10) + (c * 6) Där

  • a = antal GP-instanser
  • b = antal BC-instanser
  • c = antal olika grupper för virtuella datorer

I följande lista förklaras de tal som används i formeln:

  • 5 är antalet IP-adresser som reserverats av Azure
  • 6 adresser per GP-instans (3 för den inledande distributionen, 3 för en eventuell skalningsåtgärd)
  • 10 adresser per BC-instans (5 för den inledande distributionen, 5 för en eventuell skalningsåtgärd)
  • 6 adresser per virtuell datorgrupp

Viktigt!

Eftersom det finns en gräns för hur många virtuella datorer som kan ansluta till en grupp kan brist på utrymme i en befintlig grupp leda till att en virtuell datorgrupp med identiska specifikationer skapas. Det är möjligt för ett undernät med ett stort antal instanser att ha flera datorgrupper med samma konfiguration och överskrida 9 grupper för virtuella datorer.

Exempel 1

Du planerar att ha tre generell användning och två Affärskritisk instanser distribuerade till samma undernät. Alla instanser har samma underhållsfönster och körs på samma maskinvarukonfiguration.

Så här ansluter du dessa värden till formeln: 5 + (3 * 6) + (2 * 10) + (1 * 6) = 49

Eftersom IP-intervall definieras i krafter på 2, för att stödja 49 IP-adresser, kräver ditt undernät ett minsta IP-intervall på 64 (2^6) för den här distributionen. Reservera undernätet med en nätmask på /26.

Exempel 2

Du planerar att distribuera totalt sju instanser till samma undernät, fyra generell användning och tre Affärskritisk instanser. Tre är dev/test-instanser som körs på Standard-seriens maskinvara med ett standardunderhållsfönster (virtuell datorgrupp 1), medan de återstående fyra är i produktion och körs på Premium-seriens maskinvara med en helgunderhållsperiod (virtuell datorgrupp 2).

Så här ansluter du dessa värden till formeln: 5 + (4 * 6) + (3 * 10) + (2 * 6) = 71

Eftersom IP-intervall definieras i 2-krafter, för att stödja 71 IP-adresser, kräver ditt undernät ett minsta IP-intervall på 128 (2^7) för den här distributionen. Du måste reservera undernätet med en nätmask på /25.

Varning

Även om det är möjligt att distribuera SQL-hanterade instanser till ett undernät med färre IP-adresser än vad formeln antyder, bör du alltid överväga att använda större undernät i stället för att undvika framtida problem som beror på brist på IP-adresser, till exempel oförmågan att skapa ytterligare instanser i undernätet eller skala befintliga instanser.

Uppdateringsscenarier

Under en skalningsåtgärd kräver instanser tillfälligt ytterligare IP-kapacitet som är beroende av tjänstnivå.

I följande tabell visas det tillfälliga antalet ytterligare IP-adresser som krävs för en skalningsåtgärd som inte kräver att en ny virtuell datorgrupp skapas:

Tjänstenivå Scenario Ytterligare adresser
GP Skala virtuella kärnor 3
GP Skalningslagring 0
GP Växla till BC 5
BC Skala virtuella kärnor 5
BC Skalningslagring 5
BC Växla till GP 3

Åtgärder som resulterar i att skapa en ny grupp för virtuella datorer, till exempel att ändra en maskinvarugenerering eller underhållsperiod, kräver ytterligare 6 permanenta adresser för den nya gruppen.

Nästa steg