V zásadě může být kontejner již spuštěn, ale pro lepší kompatibilita s LXC je třeba zlepšit obsah. Jako příklad jsem použil šablonu k vytvoření kontejneru centos (/usr/share/lxc/templates/lxc-centos), konkrétně obsah funkcí configure_centos a configure_centos_init s malou úpravou. Věnujte zvláštní pozornost vytvoření skriptu etc/init/power-status-changed.conf bez něj, kontejner nebude možné správně vypnout. Nebo inittab kontejner musí obsahovat pravidlo jako: "p0::powerfail:/sbin/init 0" (v závislosti na distribuci).

/etc/init/power-status-changed.conf

# power-status-changed - vypnutí na SIGPWR
#
start na napájení-stav-změněn

Exec /sbin/shutdown -h nyní „SIGPWR přijato“

/etc/init/start-ttys.conf

#
# Tato služba spustí nakonfigurovaný počet gettys.
#

# vytvořte prosím soubor start-ttys.override a vložte tam své změny.

Env ACTIVE_CONSOLES=/dev/tty
env X_TTY=/dev/tty1
úkol
skript
. /etc/sysconfig/init
pro tty v $(echo $ACTIVE_CONSOLES); dělat
[ "$RUNLEVEL" = "5" -a "$tty" = "$X_TTY" ] && pokračovat
initctl start tty TTY=$tty
hotovo
koncový skript

/etc/init/console.conf

# konzole - getty
#
# Tato služba udržuje getty na konzole z místa, kde je systém
# se spustil, dokud se znovu nevypne.

Start na zastaveném rc RUNLEVEL=
zastavit na úrovni běhu [!2345]
env kontejner

Respawn
#exec /sbin/mingetty --nohangup --noclear /dev/console
exec /sbin/agetty -8 38400 /dev/console

/etc/init/tty.conf

# tty - getty
#
# Tato služba udržuje getty na zadaném zařízení.
#
# Neupravujte tento soubor přímo. Pokud chcete změnit chování,
# vytvořte prosím soubor tty.override a vložte tam své změny.

Zastavte na úrovni běhu

Respawn
například $TTY
#exec /sbin/mingetty --nohangup $TTY
exec /sbin/agetty -8 38400 $ TTY
použití "tty TTY=/dev/ttyX - kde X je ID konzoly"

Zkoušel jsem použít mingetty v migrovaném kontejneru se systémem CentOS 6.6, ale odmítl pracovat s chybou v protokolech:
# /sbin/mingetty --nohangup /dev/console console: žádné ovládání tty: Operace není povolena

LXC lze ovládat přes libvrt, pomocí ovladače lxc:///, ale tato metoda je nebezpečná a RedHat hrozí odebráním podpory z distribuce.
Pro ovládání přes libvrt v Pacemaker existuje zdrojový skript ocf:heartbeat:VirtualDomain, který může ovládat jakýkoli VM v závislosti na ovladači. Funkce zahrnují živou migraci pro KVM. Myslím, že pomocí kardiostimulátoru Správa KVM, bude podobný, ale nepotřeboval jsem to.

Práce s Dockerem v clusteru

Spusťte docker-storage-setup:
# docker-storage-setup Zaokrouhlení velikosti na plný fyzický rozsah 716,00 MiB Vytvořen logický svazek "docker-poolmeta".
Logický svazek „docker-pool“ byl vytvořen.
VAROVÁNÍ: Převod logického svazku shared_vg-ex/docker-pool a shared_vg-ex/docker-poolmeta na svazky dat a metadat.
TOTO ZNIČÍ OBSAH LOGICKÉHO SVAZKU (systém souborů atd.) Převedený sdílený_vg-ex/docker-pool na tenký fond.
Logický svazek "docker-pool" se změnil. #lvs | grep docker-pool docker-pool shared_vg-ex twi-aot--- 17,98 g 14,41 2,54 Docker používá tenký zřízený svazek, což omezuje jeho použití v clusteru. Takový svazek nemůže být aktivní na více uzlech současně. Pojďme nakonfigurovat LVM tak, aby svazky ve skupině shared_vg-ex nebyly automaticky aktivovány. Chcete-li to provést, musíte v souboru /etc/lvm/lvm.conf (na všech uzlech) explicitně zadat skupiny (nebo jednotlivé svazky), které budou automaticky aktivovány: auto_activation_volume_list = [ "shared_vg" ] Přeneseme ovládání tohoto svazku na kardiostimulátor:.

# pcs resource create lvm-docker-pool LVM volgrpname=shared_vg-ex exclusive=yes # pcs omezení order start clvmd-clone then lvm-docker-pool # pcs constraint colocation add lvm-docker-pool with clvmd-clone Now group volumes
shared_vg-ex bude aktivován na uzlu, kde je prostředek spuštěn lvm-docker-pool Docker použije vyhrazenou IP pro kontejnery NAT z externí sítě. Opravíme to v konfiguraci:# cat /etc/sysconfig/docker-network DOCKER_NETWORK_OPTIONS="--ip=10.1.2.10 -fixed-cidr=172.17.0.0/16" Nebudeme konfigurovat samostatný most, necháme jej použít výchozí

docker0
, stačí opravit síť pro kontejnery. Snažil jsem se naznačit vhodnou síť pro kontejnery, ale narazil jsem na nepochopitelné chyby. Google naznačil, že nejsem jediný, a tak jsem se spokojil s prostou opravou sítě, kterou si Docker pro sebe vybral. Docker také nezastaví most, když je vypnutý a neodstraní IP adresu, ale protože most není připojen k žádné

Základní nastavení je hotové, naplníme cluster příslušnými prostředky. Protože za Docker bude odpovědná sada zdrojů, je vhodné je seskupit. Všechny prostředky ve skupině běží na stejném uzlu a spouštějí se postupně podle pořadí ve skupině. Ale musíte vzít v úvahu, že pokud jeden ze zdrojů skupiny selže, celá skupina bude migrovat do jiného uzlu. A také, když vypnete jakýkoli zdroj ve skupině, vypnou se také všechny následující zdroje. Prvním zdrojem skupiny bude svazek vytvořený LVM:
# pcs skupina prostředků přidat docker lvm-docker-pool
Vytvoříme zdroj - IP adresu vydanou Dockerem:
# pcs resource create dockerIP IPaddr2 --group docker --after lvm-docker-pool ip=10.1.2.10 cidr_netmask=24 nic=br0.12
Kromě svazků LVM používá Docker k ukládání svých dat také souborový systém. Proto musíte vytvořit další sekci pod kontrolou Pacemaker. Protože tato data potřebuje pouze spuštění Dokceru, bude zdroj obyčejný.
# lvcreate -L 500M -n docker-db shared_vg # mkfs.xfs /dev/shared_vg/docker-db # pcs resource create fs-docker-db Filesystem fstype=xfs device=/dev/shared_vg/docker-db directory=/var /lib/docker --group docker --after dockerIP
Nyní můžete přidat samotného démona Docker:
# pcs resource create dockerd systemd:docker --group docker --after fs-docker-db
Po úspěšném spuštění prostředků skupiny se v uzlu, kde se Docker usadil, podíváme na jeho stav a ujistíme se, že je vše v pořádku.

informace o dockeru:

# docker info Kontejnery: 5 Obrázky: 42 Ovladač úložiště: devicemapper Název fondu: shared_vg--ex-docker--pool Velikost bloku: 524,3 kB Systém záložních souborů: xfs Datový soubor: Soubor metadat: Využitý datový prostor: 2,781 GB Datový prostor Celkem: 19,3 GB dostupného datového prostoru: 16,52 GB Použitý prostor pro metadata: 852 kB Prostor pro metadata Celkem: 33,55 MB Dostupný prostor pro metadata: 32,7 MB Udev Sync Podporováno: true Verze knihovny: 1.02.93-RHEL7 (2015-01-28) Nativní Spouštěcí ovladač: -0.2 Verze jádra: 3.10.0-229.7.2.el7.x86_64 Operační systém: CentOS Linux 7 (jádrových) CPU: 4 Celková paměť: 3,703 GiB Název: cluster-2

S Dockerem již můžete pracovat jako obvykle. Abychom však obrázek dokončili, vytvořte a přidejte do našeho clusteru registr Docker. Pro registr použijeme samostatnou IP a jméno 10.1.2.11 (dregistry) a souborové úložiště obrázků bude umístěno v samostatné sekci.
# lvcreate -L 10G -n docker-registry shared_vg # mkfs.ext4 /dev/shared_vg/docker-registry # mkdir /mnt/docker-registry # pcs resource create docker-registry Systém souborů fstype=ext4 device=/dev/shared_vg/docker -adresář registru=/mnt/docker-registry --group=docker –after=dockerd # pcs resource create registryIP IPaddr2 --group docker --after docker-registry ip=10.1.2.11 cidr_netmask=24 nic=br0.12
V uzlu, kde běží Docker, vytvoříme registr kontejnerů:
# docker create -p 10.1.2.11:80:5000 -e REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/var/lib/registry -v /mnt/docker-registry:/var/lib/registry -h dregistry --name=dregistry registry:2 Nastavení přesměrování port do kontejneru (10.1.2.11:80 → 5000). Zahrnutý adresář /mnt/docker-registry. Název hostitele a název kontejneru.
Výstup dockeru ps -a zobrazí vytvořený kontejner připravený ke spuštění.

Dejme to kontrolu Pacemakerovi. Nejprve si stáhněte nový zdrojový skript:
# wget -O /usr/lib/ocf/resource.d/heartbeat/docker https://raw.githubusercontent.com/ClusterLabs/resource-agents/master/heartbeat/docker # chmod +x /usr/lib/ocf/ resource.d/heartbeat/docker
Je důležité zajistit, aby zdrojové skripty byly identické na všech uzlech, jinak může dojít k překvapením. Samotný prostředek skriptu „docker“ může vytvořit požadované kontejnery dané parametry jejich stažením z registru. Proto můžete jednoduše používat Docker běžící neustále na uzlech clusteru s společný rejstřík a osobní úložiště. A Pacemaker ovládá pouze jednotlivé kontejnery, ale to není tak zajímavé a nadbytečné. Ještě jsem nepřišel na to, co dělat s Dockerem.
Přenesme tedy kontrolu nad hotovou nádobou na Pacemaker.
# pcs resource create dregistry docker reuse=true image="docker.io/registry:2" --group docker --after registryIP opětovné použití=pravda – důležitý parametr, jinak bude kontejner po zastavení smazán. obraz Musíte zadat úplné souřadnice kontejneru, včetně registru a značky. Skript prostředku vybere připravený kontejner podle názvu registr a spustí se.
Pojďme přidat náš místní registr do konfigurace Dockeru na uzlech clusteru (/etc/sysconfig/docker).
ADD_REGISTRY="--add-registry dregistry" INSECURE_REGISTRY="--insecure-registry dregistry" Nepotřebujeme HTTPS, takže jej deaktivujeme pro místní registr.

Poté restartujeme docker service systemctl restart docker na uzlu, kde se nachází, nebo restartujeme dockerd pcs resource na libovolném uzlu v clusteru. A můžeme využít možnosti našeho osobního registru na 10.1.2.11 (dregistry).

Nyní na příkladu kontejnerů Docker ukážu, jak pracovat se šablonami v Pacemakeru. Bohužel, schopnosti utility ks jsou zde velmi omezené. Vůbec neví, jak používat šablony jako takové, ale pro omezení umožňuje vytvořit některá spojení, ale pracovat s nimi ks není pohodlné. Naštěstí přichází na pomoc možnost upravit konfiguraci clusteru přímo v souboru xml:
# pcs cluster cib > /tmp/cluster.xml # upravit podle potřeby # pcs cluster cib-push /tmp/cluster.xml

Prostředky dockeru musí splňovat následující požadavky:

• je na stejném uzlu jako prostředky skupiny docker
• spustit po všech prostředcích skupiny docker
• kontejnery musí být vzájemně nezávislé na svém stavu

Nejprve si vytvoříme tři experimentální kontejnery, pro které jsem použil kontejner s Nginx. Kontejner je předem stažen a odeslán do místního registru:
# docker pull nginx:latest # docker push nginx:latest # pcs resource create doc-test3 docker reuse=false image="dregistry/nginx:latest" --disabled # pcs resource create doc-test2 docker reuse=true image="dregistry /nginx:latest" --disabled # pcs resource create doc-test docker reuse=true image="dregistry/nginx:latest" --disabled Zdroje jsou vytvořeny zakázány, jinak se pokusí spustit a v závislosti na štěstí uzlu.

Do čerstvě nahraného xml přidáme fond zdrojů. Definování společného umístění (sekce):
Tady to začíná obecné sdružení (kolokační sada, id="docker-col") s požadavkem soužití na stejném uzlu ( skóre="INFINITY"). První sloučení zdrojů ( id="docker-col-0") s vlastnostmi:

• současné spuštění zdrojů ( seequential="false")
• zdroje nejsou závislé na postavení toho druhého ( require-all="false")
• role zdrojů ( role="Zahájeno")

Objednávací sada, který určuje pořadí, ve kterém jsou zdroje spouštěny:
Zde je to transparentnější, nejprve spustíme zdroje skupiny přístavní dělník, pak hromadně a nezávisle na všech kontejnerech.

Po načtení změněné konfigurace lze kontejner bezpečně zapnout/vypnout a smazat. To neovlivní provoz ostatních zdrojů. Požadavek na sdílené umístění však vynutí přesun všech přidružených zdrojů do jiného uzlu clusteru v případě přenosu jakéhokoli zdroje. Na výstupu ks tato nastavení vypadají takto:
omezení # ks --plné | grep -i set Sady zdrojů: nastavit ukotvitelný panel (id:order_doc-0) nastavit doc-test doc-test2 doc-test3 sekvenční=false required-all=false (id:order_doc-1) (id:order_doc) Sady prostředků: nastavit doc-test doc-test2 doc-test3 role=Zahájeno sekvenční=false required-all=false (id:docker-col-0) nastavit ukotvitelný panel (id:docker-col-1) skóre nastavení=NEKONEČNO (id:docker-col )

Šablony zdrojů jsou zpracovány podobným způsobem. Vytvořme šablonu pro kontejner LXC (v sekci):

Do kterého si zapíšeme hlavní parametry zdroje. A přepišme nastavení prostředků, aby bylo možné používat tuto šablonu:

Po aktualizaci konfigurace byl výstup vlastností prostředku velmi krátký:
# pcs resource show lxc-racktables Zdroj: lxc-racktables (template=lxc-template) Atributy: container=lxc-racktables config=/var/lib/lxc/lxc-racktables/config
Je pravda, že vytváření nových zdrojů pomocí počítačů pomocí šablon zatím nebude fungovat.
Zbývá opravit pořadí spouštění LXC kontejnerů v podobné asociaci jako u Dockeru.

Chcete-li ovládat Pacemaker, můžete nainstalovat balíček crmsh z úložiště

, Decentralizované sítě

Chci vám říci o jiném způsobu, jak načíst rovnováhu. O Pacemakeru a IPaddr (resource agent) a jejich nastavení pro Active/Passive cluster již bylo řečeno poměrně hodně, ale našel jsem velmi málo informací o organizaci plnohodnotného Active/Active clusteru pomocí tohoto modulu. Pokusím se tuto situaci napravit.

Nejprve vám řeknu podrobněji, proč je tato metoda vyvažování pozoruhodná:

• Nedostatek externího balanceru- Na všech uzlech v clusteru je nakonfigurována jedna společná virtuální IP adresa. Všechny žádosti jsou odesílány na něj. Uzly reagují na požadavky na tuto adresu náhodně a na základě vzájemné dohody.
• Vysoká dostupnost- Pokud jeden uzel spadne, jeho zodpovědnost převezme jiný.
• Snadné nastavení- Konfigurace se provádí pouze 3-5 příkazy.

Vstupní data

Podívejme se na obrázek na začátku článku, uvidíme následující zařízení:

• Brána- IP: 192.168.100.1
• HostA- IP: 192.168.100.101
• HostB- IP: 192.168.100.102
• HostC- IP: 192.168.100.103

Klienti budou kontaktovat externí adresu naší brány, která všechny požadavky přesměruje na virtuální IP 192.168.100.100, která bude nakonfigurována na všech třech uzlech našeho clusteru.

Příprava

Nejprve se musíme ujistit, že se všechny naše uzly mohou navzájem kontaktovat pomocí jediného názvu hostitele, kvůli spolehlivosti je lepší okamžitě přidat adresy uzlů do /etc/hosts:

Nainstalujme všechny potřebné balíčky:

Při instalaci pcs vytvoří uživatele hacluster, dejme mu heslo:

Vytvoříme a spustíme cluster „Cluster“ se třemi uzly:

Podívejme se na výsledek:

Závěr

Stav clusteru: Poslední aktualizace: Čt 19. ledna 12:11:49 2017 Poslední změna: Út 17. ledna 21:19:05 2017 haclusterem přes crmd na hostA Zásobník: corosync Aktuální DC: hostA (verze 1.1.14-70404b0) - oddíl s nakonfigurovanými uzly kvora 3 a 0 zdroji Online: [ hostA hostB hostC ] Stav PCSD: hostA: Online hostB: Online hostC: Online

Některé kroky byly vypůjčeny z článku Lelik13a, díky jemu za to.

V našem konkrétním případě náš cluster nevyžaduje kvorum ani stonith, takže můžeme bezpečně zakázat obojí:

V budoucnu, pokud budete mít zdroje, pro které je to nutné, můžete se obrátit na článek Silvar.

Pár slov o MAC adresách

Než začneme, musíme pochopit, že všechny naše uzly budou nakonfigurovány se stejnou IP a stejnou mac adresou, na kterou budou střídavě reagovat.

Problém je v tom, že každý switch funguje tak, že si při provozu vytváří vlastní tabulku switchů, ve které je každá mac adresa spojena s konkrétním fyzickým portem. Přepínací tabulka se sestavuje automaticky a slouží k odlehčení sítě od „zbytečných“ paketů L2.

Pokud je tedy mac adresa v přepínací tabulce, pakety budou odeslány pouze na jeden port, kterému je přiřazena stejná mac adresa.

To nám bohužel nevyhovuje a musíme zajistit, aby všichni naši hostitelé v clusteru „viděli“ všechny tyto pakety současně. Jinak toto schéma nebude fungovat.

Nejprve se musíme ujistit, že mac adresa, kterou používáme, je multicastová adresa. To znamená, že je v rozsahu 01:00:5E:00:00:00 - 01:00:5E:7F:FF:FF . Po přijetí paketu pro takovou adresu jej náš přepínač předá na všechny ostatní porty kromě zdrojového. Navíc některé spravované přepínače umožňují konfigurovat a definovat více portů pro konkrétní MAC adresu.

Možná budete také muset zakázat dynamickou kontrolu ARP, pokud ji váš přepínač podporuje, protože může způsobit zablokování odpovědí arp od vašich hostitelů.

Nastavení prostředku IPaddr

Nyní se dostáváme k nejzajímavější části.

V současné době existují dvě verze IPaddr s podporou klonování:

IPaddr2(ocf:heartbeat:IPaddr2) - Standardní agent prostředků pro vytváření a provozování virtuální IP adresy. Obvykle se instaluje se standardním balíčkem resource-agents.

• IPaddr3(ocf:percona:IPaddr3) - Vylepšená verze IPaddr2 od Percona.
  Tato verze obsahuje opravy zaměřené na práci konkrétně v režimu klonování.
  Je vyžadována samostatná instalace.

Chcete-li nainstalovat IPaadr3, spusťte tyto příkazy na každém hostiteli:

Vytvořme zdroj pro naši virtuální IP adresu:

clusterip_hash- zde je třeba zadat požadovaný typ distribuce požadavku.
Mohou existovat tři možnosti:

• sourceip - distribuce pouze podle zdrojové IP adresy, tím je zajištěno, že všechny požadavky ze stejného zdroje půjdou vždy na stejného hostitele.
• sourceip-sourceport - distribuce podle zdrojové IP adresy a odchozího portu. Každé nové připojení přejde na nového hostitele. Nejlepší možnost.
• sourceip-sourceport-destport - distribuce podle zdrojové IP adresy, odchozího portu a cílového portu. Poskytuje nejlepší distribuci, což je důležité, pokud máte několik služeb spuštěných na různých portech.

Pro IPaddr2 musíte zadat parametr mac=01:00:5E:XX:XX:XX s adresou mac z rozsahu vícesměrového vysílání. IPaddr3 jej nainstaluje automaticky.

Nyní naklonujme náš zdroj:

Tato akce vytvoří v iptables následující pravidlo:

Jak vidíte, je zde použit modul CLUSTERIP.

Funguje to takto:

Všechny pakety přicházejí do tří uzlů, ale všechna tři jádra Linuxu vědí, kolik uzlů přijímá pakety, všechna tři jádra číslují přijaté pakety podle jediného pravidla, a protože vědí, kolik uzlů celkem a počet jeho uzlů, každý server zpracovává pouze jeho část paketů, zbytek paketů server ignoruje - zpracovávají je jiné servery.

Přečtěte si o tom více v tomto

V tomto článku popíšu instalaci a konfiguraci Active/Active clusteru založeného na Pacemaker, Corosync 2.xa CLVM pomocí sdíleného úložiště. Ukážu vám, jak přizpůsobit tento cluster pro práci s kontejnery LXC a Docker. Popíšu příkazy pro práci s clusterem. A vzpomenu si na hrábě, do kterého jsem se dostal, což, doufám, ulehčí osud dalším gaunerům.

Jako serverové distribuce budu používat CentOS 7 + epel a nejnovější verze balíčků v nich. Hlavním nástrojem pro práci s Pacemakerem bude PCS (konfigurační systém kardiostimulátoru/korosync).

Příprava serveru

Použil jsem dvouuzlovou konfiguraci, ale počet lze podle potřeby zvýšit. Servery mají společné sdílené úložiště připojené přes SAS. Pokud to nemáte po ruce, můžete použít úložiště připojené přes FC nebo iSCSI. Budete potřebovat dva svazky, jeden pro obecné potřeby, druhý pro Docker. Jeden svazek můžete rozdělit na dvě části.
Nainstalujte CentOS 7, epel repository a nakonfigurujte síť. Použití bondingu pro síťová rozhraní a multipath pro SAS je žádoucí. Pro práci s různými vlany nakonfigurujeme příslušné br0.VID mosty, ke kterým pak navážeme LXC kontejnery. Nebudu popisovat detaily - vše je standardní.