Udostępnij przez

Zarządzanie konfiguracją obciążenia

Ten artykuł zawiera wskazówki dotyczące programu Azure Operator Service Manager (AOSM) umożliwiające optymalizowanie projektowania schematów grup konfiguracji (CGS) i działania wartości grup konfiguracji (CGV). Dostawcy funkcji sieciowej (NF), operatorzy telco i ich partnerzy powinni pamiętać o tych praktykach podczas dołączania i wdrażania NFs.

Co to jest schemat JSON?

Schemat JSON to standard Internet Engineering Task Force (IETF), który zapewnia format danych JSON wymagany dla danej aplikacji oraz określa, jak się z nimi komunikować. Stosowanie takich standardów dla dokumentu JSON umożliwia wymuszanie spójności i ważności danych w danych JSON

Gdzie jest używany schemat JSON?

  • Usługa AOSM używa notacji schematu JSON jako meta-schematu we właściwościach obiektu ConfigurationGroupSchemaPropertiesFormat usługi CGSschemaDefinition.
  • Usługa AOSM umożliwia projektantowi i wydawcy określenie schematu JSON, w którym operator musi podać dane (wartości JSON) podczas tworzenia wystąpienia SNS/NF.
  • Rozwiązanie AOSM umożliwia opcjonalne lub wymagane właściwości meta-schematu. Jeśli właściwość jest oznaczona jako wymagana, musi być określona w wartościach Json.

Jakie słowa kluczowe JSON są obsługiwane?

W przypadku meta-schematu CGS, AOSM implementuje obsługę standardowych słów kluczowych JSON dla każdego typu osobno.

  • W przypadku typów obiektów obsługiwane słowo kluczowe jest ograniczone przez zasady filtrowania. Zobacz Schemat JSON — obiekt
  • W przypadku typów ciągów obsługa słów kluczowych nie jest ograniczona ani filtrowana. Zobacz Schemat JSON — ciąg
  • W przypadku typów liczbowych obsługa słów kluczowych nie jest ograniczona ani filtrowana. Zobacz Schemat JSON — numeryczne

Pola opcjonalne i wymagane

Właściwość jest zadeklarowana jako opcjonalna przez dołączenie słowa kluczowego required , które pomija właściwość opcjonalną. required Jeśli słowo kluczowe nie jest określone, wszystkie właściwości są uznawane za wymagane. Do obsługi opcjonalnego typu właściwości jest wymagany co najmniej jeden wymagany typ właściwości.

{
"type": "object",
"properties": {
  "abc": {
    "type": "integer",
     "default": 30
  },
  "xyz": {
    "type": "string",
    "default": "abc123"
  }
 }
"required":  ["abc"]
}

Wartości domyślne w schemacie JSON

W przypadku właściwości opcjonalnych usługa AOSM implementuje niestandardową metodę obsługi wartości domyślnych. Gdy wartość domyślna jest zdefiniowana w meta-schemacie CGS, AOSM używa tej wartości tam, gdzie właściwość jest brakująca lub niezdefiniowana w danych wejściowych CGV. Logika modułu sprawdzania poprawności AOSM zasadniczo ustawia wartość CGV na wartość domyślną, jeśli operator nie dostarczy wartości.

Jak zdefiniować wartości domyślne

Wartości domyślne muszą być określone w właściwościach lub elementach tablicy. W poniższym przykładzie pokazano wartości domyślne dla liczby całkowitej oraz testowanie typów właściwości.

{
"type": "object",
"properties": {
  "abc": {
    "type": "integer",
     "default": 30
  },
  "xyz": {
    "type": "string",
    "default": "abc123"
  }
 }
}

Reguły definiowania wartości domyślnych

Podczas sprawdzania poprawności wartości domyślnej są stosowane następujące reguły. Podczas używania wartości domyślnych należy wziąć pod uwagę następujące reguły, aby zapewnić oczekiwane wyniki:

  • Wartość domyślna nie powinna być stosowana do wymaganej właściwości.
  • Wartość domyślna jest obliczana w kolejności od góry w dół, z której słowo kluczowe jest widoczne po raz pierwszy.
  • Jeśli wartość właściwości istnieje w wejściowym CGV, tylko elementy podrzędne tych właściwości są oceniane dla wartości domyślnych.
  • Jeśli wartość właściwości nie istnieje w wejściowym CGV, jest obliczana dla wartości domyślnej wraz z wszystkimi elementami podrzędnymi.
  • Gdzie wartość właściwości jest typu obiektu, a ani ono, ani jego klucz nie istnieją w wejściowym CGV, to nie są oceniane żadne wartości domyślne dla obiektu.

Zagadnienia dotyczące usługi CGS

W miarę upływu czasu zalecane podejście do najlepszych schematów grup konfiguracji projektu uległo zmianie. Chociaż oryginalne podejście 1-CGS pozostaje obsługiwane, w przypadku wszystkich nowych projektów zalecamy podejście 3-CGS. Dodatkowe szczegóły dotyczące konwertowania z 1-CGS na 3-CGS można zażądać.

Podejście 1-CGS

Początkowo zalecano używanie tylko jednej usługi CGS dla całego NF. Te skonsolidowane parametry specyficzne dla lokacji, specyficzne dla wystąpienia i zabezpieczeń są powiązane z pojedynczym zestawem obiektów grupy konfiguracji. Unikano wielu zestawów obiektów, z wyjątkiem rzadkich przypadków, w których usługa składała się z wielu składników. Wielu partnerów pomyślnie wdrożyło usługi przy użyciu tego podejścia i jest dalej wspierane.

Podejście 3-CGS

Ostatnio zaleca się używanie co najmniej trzech CGS dla całego NF, organizując parametry w zestawach grup konfiguracji specyficznych dla lokacji, wystąpienia oraz zabezpieczeń. Przykłady parametrów specyficznych dla witryny to adresy IP lub unikatowe nazwy. Przykłady specyficznych parametrów instancji to limity czasu lub poziomy debugowania. Przykłady parametrów specyficznych dla zabezpieczeń to hasła lub certyfikaty. W przypadku parametrów specyficznych dla zabezpieczeń usługa Azure Keyvault jest używana do przechowywania bezpiecznych wartości.

Projektowanie zestawów obiektów 3-CGS

Podczas projektowania obiektów 3-CGS należy wziąć pod uwagę następujące wytyczne dotyczące meta-schematu;

  • Wybierz parametry do wyświetlenia.
    • Ogólną zasadą jest uwidocznienie tych parametrów za pomocą operacji bezpośredniej, takich jak SKU obliczeniowe lub wartość konfiguracyjna Helm.
    • W przeciwieństwie do parametru, na który działa inny agent, takiego jak cloudinit dane użytkownika.
  • Posortuj parametry do zestawów specyficznych dla miejsca, specyficznych dla instancji i związanych z bezpieczeństwem.
  • Zdefiniuj wymagane i opcjonalne parametry.
    • W przypadku parametrów opcjonalnych zdefiniuj rozsądną wartość domyślną.
  • Upewnij się, że nie ma nakładających się parametrów między obiektami usługi CGS.

W poniższym przykładzie pokazano przykładowe ładunki CGS oraz odpowiadające im ładunki CGV.

Ładunek CGS:

{ 
  "type": "object", 
  "properties": {
    "abc": { 
      "type": "integer", 
      "default": 30
    }, 
    "xyz": { 
      "type": "integer", 
      "default": 40
    },
    "qwe": {
      "type": "integer"
    }
   }
   "required": "qwe"
}

Odpowiadający ładunek CGV przekazany przez operatora:

{
"qwe": 20
}

Wynikowy ładunek CGV wygenerowany przez program Azure Operator Service Manager:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Zagadnienia dotyczące wartości grupy konfiguracji

Przed przesłaniem utworzenia zasobu CGV można sprawdzić, czy schemat i wartości bazowego pliku YAML lub JSON są zgodne z oczekiwanymi odpowiednimi usługami CGS. W tym celu jedną z opcji jest użycie rozszerzenia YAML dla programu Visual Studio Code.

  • Last updated on