Priority Buckets und Bezeichner

  • Updated on Aug 1, 2023
  • 8 minute(s) read
Prev Next

In diesem Abschnitt wird erläutert, wie mithilfe von Verbesserungen an der Infrastruktur Kerndienste optimiert und Startsequenzen von Diensten gesteuert werden.

Priority Buckets für Dienste

Derzeit werden alle Dienste mit der gleichen Priorität gestartet. Allerdings wird in bestimmten Szenarien ein Anwendungsdienst oder Kerndienst vor einem anderen Kerndienst gestartet, von dem dieser abhängig ist. Dies führt zu zahlreichen Neustarts von Diensten und einer Verzögerung bei dem Start aller Dienste nach einem Neustart des iNode.
Um diese Verzögerung zu verhindern, weist die Infrastruktur Kerndiensten Priority Buckets zu, um die Startsequenzen von Diensten zu steuern.

Dienstabhängigkeit und Empfehlungen in Bezug auf Prioritäten

Im Falle der Kerndienste von Secure Edge – DHCP, PowerDNS und Postgres – besteht folgende Dienstabhängigkeit:

  • PowerDNS ist von Postgres abhängig;
  • DHCP ist von Postgres und PowerDNS (im Falle dynamischer DNS-Aktualisierungen) abhängig.

Wir empfehlen, die Priorität (wobei 0 die höchste und 7 die geringste Priorität bedeutet) wie folgt zuzuweisen:

DienstPriorität

Postgres (Kerndienst)

0

PowerDNS (Kerndienst)

1

DHCP (Kerndienst)

2

Standardpriorität für andere Dienste

7

Die Priorität wird einem Dienst mit dem folgenden Bezeichner in der entsprechenden Pod-Spezifikation zugewiesen.

Bezeichner:

io_iotium_pod_priority: 2

Spezielle Bezeichner für Dienstspezifikationen

In diesem Abschnitt werden spezielle Bezeichner für Dienste von View Secure Edge beschrieben.

Bezeichner zur Bereitstellung von Diensten in Clustern

NameTypeErforderlichBeschreibung

_iotium_master_elect

String

Falsch

Wert: „subscribed“. Wir legen die env-Variable IOTIUM_NODE_ROLE auf Grundlage der Node-Rolle in einem Cluster als „master/slave“ fest. Diese env-Variable kann von Anwendungsdiensten genutzt werden, um zu unterscheiden, ob die Dienstinstanz in dem Cluster auf dem Master Node oder dem Slave Node ausgeführt wird.

_iotium_master_elect_ip / _iotium_master_elect_ip_prefixlen

String

Falsch

Falls festgelegt, werden _iotium_master_elect_ip und _iotium_master_elect_ip_prefixlen als die IP-Adresse/PrefixLen der Instanz des Anwendungsdienstes auf dem Master Node (dem iNode mit der Variable IOTIUM_NODE_ROLE) ausgeführt. Dafür muss _iotium_master_elect als „subscribed“ festgelegt werden.

Anwendungsdienste können je nach Node, den sie in dem Cluster ausführen, Entscheidungen in Bezug auf die Ausführung treffen.

  • Der Bezeichner „_iotium_master_elect:subscribed“ stellt sicher, dass die Anwendungsdienste diese Informationen erhalten.
  • Die Bezeichner „iotium_master_elect_ip:<IPaddress>“ und „_iotium_master_elect_ip_prefixlen“ enthalten bestimmte Informationen über die statische IP-Adresse, die für die Replica-Instanz des Dienstes genutzt wird. Die statische IP-Adresse wird auf die Replica-Instanz angewendet, die auf dem MASTER Node innerhalb eines Clusters ausgeführt wird.

Bezeichner für Kerndienste (um Konflikte mit der Zeitzoneneinstellung von Containern zu verhindern)

NameWerteErforderlichBeschreibungGültige Bereitstellungen

_iotium_core_service

true / false

True (ioTium-Kerndienst).
False (andere Dienste).

Wird genutzt, um einen Dienst als „Kerndienst“ festzulegen.
Wenn der Wert auf „true“ festgelegt ist, haben Änderungen an der Zeitzone von Containern keine Auswirkungen auf diesen Dienst; er wird weiterhin die iNode-Zeitzone nutzen.

Eigenständiges iNode und eigenständiger Cluster.

Ein Benutzer kann die Zeitzone des Containers des Anwendungsdienstes bei Bedarf ändern. Während alle Anwendungsdienste in diese Zeitzone wechseln, verbleibt der Node in der konfigurierten Zeitzone (Standardzone: UTC). Es ist wünschenswert, dass Kerndienste in derselben Zeitzone wie der Node ausgeführt werden.

Um Auswirkungen durch Änderungen an der Zeitzone von Containern zu vermeiden, müssen Kerndienste wie folgt eindeutig als Kerndienste bezeichnet werden:

"_iotium_core_service": "true" key-pair

Bezeichner für Pod-Priorität

NameWerteErforderlichBeschreibungGültige Bereitstellungen

io_iotium_pod_priority

0-2: Reserviert für ioTium
Kerndienste.
3-7: Prioritätsscheduling für Anwendungsdienste durch den Benutzer.

Falsch

Zur Bereitstellung einer Dienstverkettung genutzt.
Für einen anderen Dienst erforderliche Dienste werden zuerst gestartet, indem ihnen eine höhere Priorität zugewiesen wird. Sehen Sie sich den Abschnitt „Prioritätsscheduling“ an, um weitere Informationen zu erhalten.

Eigenständiges iNode und eigenständiger Cluster.

Bezeichner zur Verhinderung eines Neustarts eines Dienstes bei einem Ausfall des Master Cluster

NameWerteErforderlichBeschreibungGültige Bereitstellungen

_iotium_master_elect_env_volume

String

Volume-Name wird im Abschnit „Volumes“ der Pod-Spezifikation bereitgestellt.

Falsch

Geben Sie den Volume-Namen bei dem Laden der env-Variable IOTIUM_NODE_ROLE und des Clusters ein. Anstatt die env-Variablen in der Dienstspezifikation festzulegen, werden sie in die Datei „runtime.env“ in dem festgelegten Volume geschrieben.

Cluster.
Verhinderung eines Neustarts der Replica-Dienstinstanz bei einem Ausfall des Master Cluster.

Sie können bei einem Ausfall des Master Cluster die Ausfallzeiten der Cluster-Bereitstellung reduzieren. Ein Ausfall des Master Cluster führt zu einer neuen Auswahl und einem Neustart aller Dienste, die von der Node-Rolle dem Cluster abhängen. Sie können einen Mechanismus bereitstellen, sodass diese Dienste bei einem Ausfall problemlos ihre Rollen wechseln, ohne neugestartet werden zu müssen. Der Modus „Replica“ des Anwendungsdienstes mit der Konfiguration zur Verhinderung des Neustarts eines Dienstes reduziert effektiv die Ausfallzeiten bei Ausfällen des Master Cluster.

Sie können den Neustart eines Dienstes verhindern, indem Sie das Volume dort festlegen, wo die mit der Node-Rolle in Beziehung stehenden Umgebungsvariablen geschrieben sind und die Umgebungsvariablen deaktivieren, die mit denen der Dienstumgebung identisch sind.

Die beiden obigen Bezeichner helfen dabei, dies zu erreichen. Darüber hinaus müssen Sie sicherstellen, dass die DNS-Richtlinie für den Dienst auf Keine festgelegt und dass die DNS-IP-Adresse eingerichtet ist. Sehen Sie sich „PowerDNS-/Postgres-Dienstspezifikation“ an, um weitere Informationen zu erhalten.

Der Anwendungsdienst muss die Datei mit der Umgebungsvariablen auslesen können, falls diese Funktion genutzt wird.

Spezielle Bezeichner für Kerndienste

In diesem Abschnitt werden die POST-Bodys von PowerDNS, PostgreSQL, DHCP und NTP beschrieben, die die in diesem Abschnitt beschriebenen Kontrollen durchführen. Außerdem wird eine Option zur Aktivierung der Remote-Protokollierung für die Dienste erläutert.

Priorität und Einstellung von Postgres-Kerndiensten

Für den Postgres-Dienst ist die Priorität auf 0 und der Bezeichner des Kerndienstes ist auf true festgelegt. Die Image-Version des Postgres-Dienstes (iotium/postgres:12.3.0-3-amd64) ist erforderlich.

Befolgen Sie diese Schritte, um den Kerndienst Postgres zu starten:

  1. Um einen bestehenden Postgres-Dienst zu aktualisieren, bearbeiten Sie die Spezifikation und nehmen Sie die erforderlichen Änderungen an den IP-Adressen, Secret-IDs, der Netzwerk-ID, Cluster-ID und dem DNS vor.
  2. Stellen Sie sicher, dass Sie in dem Abschnitt „Bezeichner“ der Pod-Spezifikation die folgenden Bezeichner hinzufügen:
"io_iotium_pod_priority": "0"
"_iotium_core_service": "true"

Beispiel einer Postgres-Dienstspezifikation:

{
	"name": "DB",
	"labels": {
		"io_iotium_template": "postgresqacluster",
		"_iotium_master_elect": "subscribed",
		"_iotium_master_elect_ip": "10.102.0.2",
		"_iotium_master_elect_ip_prefixlen": "24",
		"_iotium_master_elect_env_volume": "iotium-vol",
		"_iotium_master_elect_set_env": "disable",
                       "io_iotium_pod_priority": "0",
                       "_iotium_core_service": "true"
	},
	"networks": [{
		"network_id": "n-82e48b339e69df75"
	}],
	"services": [{
		"image": {
			"name": "iotium/postgres",
			"version": "12.3.0-3-amd64"
		},
		"docker": {
			"environment_vars": {
				"POSTGRESQL_PASSWORD": "postgres",
				"DHCP_DB_NAME": "dhcp",
				"DHCP_DB_USER": "dhcp",
				"DHCP_DB_PASSWORD": "dhcp",
				"DNS_DB_NAME": "pdns",
				"DNS_DB_USER": "pdns",
				"DNS_DB_PASSWORD": "pdns",
				"POSTGRESQL_MASTER_HOST": "10.102.0.2"
			},
			"volume_mounts": [{
					"name": "datadir",
					"mount_path": "/bitnami/postgresql"
				},
				{
					"mount_path": "/config/",
					"name": "iotium-vol",
                                                           "read_only": wahr
				}
			]
		},
		"liveness_probe": {
			"exec": {
				"command": ["/healthcheck.sh"]
			},
			"initial_delay_seconds": 10,
			"timeout_seconds": 5,
			"period_seconds": 30,
			"success_threshold": 1,
			"failure_threshold": 3
		},
		"image_pull_policy": "IfNotPresent"
	}],
	"volumes": [{
		"name": "datadir",
		"emptyDir": {}
	}, {
		"name": "iotium-vol",
		"emptyDir": {}
	}],
	"dns_policy": "None",
	"dns": [
		"8.8.8.8",
		"10.102.0.3"
	],
	"termination_grace_period_in_seconds": 60,
	"kind": "REPLICA",
	"cluster_id": "67664978-55c3-4e56-b04e-a1dd59a5496e",
	"node_selector": {
		"_iotium.cluster.candidate": wahr
	}
}

Priorität und Einstellung von PowerDNS-Kerndiensten

Für den PowerDNS-Dienst ist die Priorität auf 1 und der Bezeichner des Kerndienstes ist auf true festgelegt.

Die Image-Version von PowerDNS-Diensten iotium/powerdns:4.0.8-3-amd64) kann anstelle der Probescripte genutzt werden.

Befolgen Sie diese Schritte, um den Kerndienst PowerDNS zu starten:

  1. Um den bestehenden Pod zu aktualisieren, bearbeiten Sie die Pod-Spezifikation und nehmen Sie die erforderlichen Änderungen an den IP-Adressen, Secret-IDs, der Netzwerk-ID, Cluster-ID und dem DNS vor.
  2. Stellen Sie sicher, dass Sie in dem Abschnitt „Bezeichner“ der Pod-Spezifikation die folgenden Bezeichner hinzufügen:
"io_iotium_pod_priority": "1"
"_iotium_core_service": "true"

Beispiel einer PowerDNS-Dienstspezifikation für API

Die Spezifikation in dem Beispiel wird genutzt, um einen PowerDNS-Dienst im Replica-Modus in einem Cluster auszuführen, und bei einem Ausfall des Master Cluster einen Neustart des Dienstes zu vermeiden.

{
	"name": "DNS",
	"labels": {
		"io_iotium_template": "pdns-2208",
		"_iotium_core_service": "true",
		"io_iotium_pod_priority": "1",
		"_iotium_master_elect": "subscribed",
		"_iotium_master_elect_ip_prefixlen": "24",
		"_iotium_master_elect_ip": "10.200.100.4",
		"_iotium_master_elect_set_env": "disable",
		"_iotium_master_elect_env_volume": "iotium-vol",
		"_iotium_template": "pdns-2208"
	},
	"networks": [{
		"network_id": "n-6a2c225bfb36ec6f"
	}],
	"services": [{
			"name": "pdnsrecursor",
			"image": {
				"name": "iotium/dnsrecursor",
				"version": "4.5.8-1-amd64"
			},
			"docker": {
				"environment_vars": {
					"PDNS_API_KEY": "changeme",
					"PDNS_WEBSERVER_ALLOW_FROM": "0.0.0.0/0",
					"PDNS_ALLOW_RECURSION": "",
					"PDNS_RECURSOR": ""
				},
				"volume_mounts": [{
					"name": "zonefile",
					"mount_path": "/var/pdns/zonefiles",
					"read_only": falsch
				}]
			},
			"image_pull_policy": "IfNotPresent"
		},
		{
			"image": {
				"name": "iotium/powerdns",
				"version": "4.5.4-1amd64"
			},
			"docker": {
				"environment_vars": {
					"PDNS_GPGSQL_PASSWORD": "pdns",
					"PDNS_ALLOW_DNSUPDATE_FROM": "10.200.100.5",
					"PDNS_GPGSQL_DBNAME": "pdns",
					"PDNS_GPGSQL_USER": "pdns",
					"PDNS_API_KEY": "changeme",
					"PDNS_WEBSERVER_ALLOW_FROM": "0.0.0.0/0",
					"PDNS_GPGSQL_HOST": "10.200.100.3",
					"ENABLE_REMOTE_LOGGING": "true"
				},
				"volume_mounts": [{
						"name": "zonefile",
						"mount_path": "/var/pdns/zonefiles"
					},
					{
						"name": "iotium-vol",
						"mount_path": "/iotium",
						"read_only": "true"
					},
					{
						"name": "named",
						"mount_path": "/var/pdns/config"
					},
					{
						"name": "logs",
						"mount_path": "/var/log"
					}
				]
			},
			"image_pull_policy": "IfNotPresent"
		},
		{
			"image": {
				"name": "fluent/fluent-bit",
				"version": "1.5"
			},
			"docker": {
				"volume_mounts": [{
						"name": "logs",
						"mount_path": "/var/log"
					},
					{
						"name": "fluentbit",
						"mount_path": "/fluent-bit/etc/"
					}
				]
			},
			"image_pull_policy": "IfNotPresent"
		}
	],
	"volumes": [{
			"name": "zonefile",
			"secret_volume": {
				"secret": "217a8876-ef07-4785-bf38-600dc0f23026"
			}
		},
		{
			"name": "iotium-vol",
			"emptyDir": {}
		},
		{
			"name": "named",
			"secret_volume": {
				"secret": "ff13a50f-db22-4f5d-b36a-d24abf5bd5c7"
			}
		},
		{
			"name": "logs",
			"emptydir": {}
		},
		{
			"name": "fluentbit",
			"secret_volume": {
				"secret": "64c883e5-76f1-455d-b995-f61b9ac839e9"
			}
		}
	],
	"dns_policy": "None",
	"dns": [
		"10.200.100.4"
	],
	"kind": "REPLICA",
	"cluster_id": "1ed3a792-5a18-4b95-be25-30873654535b",
	"node_selector": {
		"_iotium.cluster.candidate": "true"
	}
}

Priorität und Einstellung von DHCP-Kerndiensten

Für den DHCP-Dienst ist die Priorität auf 2 und der Bezeichner des Kerndienstes ist auf true festgelegt.

Befolgen Sie diese Schritte, um den Kerndienst DHCP zu starten:

  1. Um den bestehenden Pod zu aktualisieren, bearbeiten Sie die Pod-Spezifikation und nehmen Sie die erforderlichen Änderungen an den IP-Adressen, Secret-IDs, der Netzwerk-ID, Cluster-ID und dem DNS vor.
  2. Stellen Sie sicher, dass Sie in dem Abschnitt „Bezeichner“ der Pod-Spezifikation die folgenden Bezeichner hinzufügen:
"io_iotium_pod_priority": "2"
"_iotium_core_service": "true"

Beispiel einer DHCP-Dienstspezifikation für API

{
	"kind": "SINGLETON",
	"name": "DHCP",
	"cluster_id": "96cfabed-9410-4b97-be56-71dd9ffc2e7f",
	"networks": [{
		"network_id": "n-4900829c7c563ffd",
		"ip_address": "172.31.0.5"
	}],
	"labels": {
		"io_iotium_pod_priority": "2",
		"_iotium_core_service": "true",
		"io_iotium_template": "dhcpqacluster",
		"io_iotium_fileName": ""
	},

	"services": [{
			"docker": {
				"volume_mounts": [{
						"mount_path": "/etc/kea/",
						"name": "dhcp3"
					},
					{
						"mount_path": "/var/lib/kea",
						"name": "leasedir"
					},
					{
						"mount_path": "/etc/keaddns/",
						"name": "ddns3"
					},
					{
						"mount_path": "/var/log",
						"name": "logs"
					}
				]
			},
			"image_pull_policy": "IfNotPresent",
			"image": {
				"version": "1.6.2-2-amd64",
				"name": "iotium/dhcpd"
			}
		},
		{
			"docker": {
				"volume_mounts": [{
						"mount_path": "/var/log",
						"name": "logs"
					},
					{
						"mount_path": "/fluent-bit/etc/",
						"name": "fluent-bit.conf"
					}
				]
			},
			"image_pull_policy": "IfNotPresent",
			"image": {
				"version": "1.5",
				"name": "fluent/fluent-bit"
			}
		}
	],

	"volumes": [{
			"secret_volume": {
				"secret": "fdbfe29a-e1b3-4c17-9a12-f2c3697ac553"
			},
			"name": "dhcp3"
		},
		{
			"emptyDir": {},
			"name": "leasedir"
		},
		{
			"secret_volume": {
				"secret": "757d6de6-3f74-40db-b7f1-0626c0b5f789"
			},
			"name": "ddns3"
		},
		{
			"emptydir": {},
			"name": "logs"
		},
		{
			"secret_volume": {
				"secret": "ab2179c7-134f-48a9-9414-afd15727e7c0"
			},
			"name": "fluent-bit.conf"
		}
	]
}

Priorität und Einstellung von NTP-Kerndiensten

Sie müssen für den NTP-Dienst keine Priorität festlegen. Legen Sie den Bezeichner des Kerndienstes auf true fest, um sicherzustellen, dass der Dienst nicht durch die Änderung der Container-Zeitzone beeinträchtigt wird.

Befolgen Sie diese Schritte, um den Kerndienst NTP zu starten:

  1. Um den bestehenden Pod zu aktualisieren, bearbeiten Sie die Pod-Spezifikation und nehmen Sie die erforderlichen Änderungen an den IP-Adressen, Secret-IDs, der Netzwerk-ID, Cluster-ID und dem DNS vor.
  2. Stellen Sie sicher, dass Sie in dem Abschnitt „Bezeichner“ der Pod-Spezifikation den folgenden Bezeichner hinzufügen:
"_iotium_core_service": "true"

Beispiel eines des Anfrage-Bodys einer NTP-Dienstspezifikation für API

{
	"kind": "SINGLETON",
	"name": "NTP",
	"cluster_id": "96cfabed-9410-4b97-be56-71dd9ffc2e7f",
	"networks": [{
		"network_id": "n-4900829c7c563ffd",
		"ip_address": "172.31.0.6"
	}],
	"labels": {
		"_iotium_template": "ntpqacluster",
		"io_iotium_template": "ntpqacluster",
		"_iotium_core_service": "true"
	},
	"services": [{
			"docker": {
				"volume_mounts": [{
					"mount_path": "/var/log",
					"name": "logs"
				}],
				"cap_add": [
					"SYS_TIME",
					"SYS_RESOURCE"
				],
				"environment_vars": {
					"ENABLE_REMOTE_LOGGING": "true"
				}
			},
			"image_pull_policy": "IfNotPresent",
			"image": {
				"version": "4.2.8p10-2-amd64",
				"name": "iotium/ntp"
			}
		},
		{
			"docker": {
				"volume_mounts": [{
						"mount_path": "/var/log",
						"name": "logs"
					},
					{
						"mount_path": "/fluent-bit/etc/",
						"name": "fluent-bit.conf"
					}
				]
			},
			"image_pull_policy": "IfNotPresent",
			"image": {
				"version": "1.5",
				"name": "fluent/fluent-bit"
			}
		}
	],
	"volumes": [{
			"emptydir": {},
			"name": "logs"
		},
		{
			"secret_volume": {
				"secret": "ab2179c7-134f-48a9-9414-afd15727e7c0"
			},
			"name": "fluent-bit.conf"
		}
	]

}