Menu
Article

Distributed Manta ausrollen

neuroserve

• 8 min read

Dieser Beitrag ist im Dezember 2017 entstanden

Nach verschiedenen Versuchen (hier, hier und hier), ist die über drei Availability Zonen (AZ) verteilte Manta-Installation jetzt geglückt. Ziel dieses Setups ist es, den Ausfall einzelner Computenodes und einer kompletten AZ ohne Datenverlust überleben zu können. Standardmässig speichert Manta immer zwei Kopien eines Objekts auf verschiedenen Computenodes. Werden mehr als zwei Kopien angefordert, werden die ersten drei über die AZs verteilt. Manta würde beim Abruf dann immer die noch verfügbare Kopie des Objekts ausliefern. Es lohnt sich also, sich dies einmal anzusehen. Leider ist das Setup für eine verteilte Manta-Installation noch etwas schlechter dokumentiert als für den Rollout in nur einer AZ. Damit die verschiedenen Schritte, die für eine erfolgreiche Installation durchgeführt werden müssen, nicht verloren gehen, führe ich sie hier nochmal auf. Insbesondere, weil Fehlkonfigurationen durchaus dazu führen könnten, dass man wieder ganz von vorn anfangen muß.

Die Grundvoraussetzungen hatte ich schon im Posting zu "AZ-Kopplung bei Triton" zusammengetragen:

  • Gekoppelte Datacenter/AZ
  • Gekoppelte SAPIs der beteiligten Datacenter/AZs
  • Übergreifendes DNS und Routing zwischen den Datacentern/AZs

Wenn das gegeben ist, sollten in jedem Datacenter die Instanzen der anderen Datacenter per DNS auflösbar sein.

[root@headnode (de-gt-3) ~]# dig +short moray.de-gt-4.srv.tgos.de
10.65.72.55
10.65.72.15
10.65.72.56
[root@headnode (de-gt-3) ~]# dig +short moray.de-gt-1.srv.tgos.de 
10.64.244.15
[root@headnode (de-gt-3) ~]#

User, die per adminui angelegt werden, sollten automatisch in die anderen Datacenter repliziert werden. 

Danach kann man nach dem Manta Operator's Guide mit dem Rollout beginnen. Die allermeisten Kommandos sollten dabei ausschliesslich in der Manta-Zone des Datacenters ausgeführt werden, welches auch das Datacenter mit der Primary-SAPI Zone ist. Fehlbedienungen können hier dazu führen, dass man die beiden Secondary Headnodes neu aufsetzen muss.

  • Zunächst wird in jedem Datacenter eine Manta-Zone erzeugt. Das entsprechende Skript ist unter /usbkey/scripts abgelegt.
  • Danach wird eine Netzwerkkonfiguration für Manta benötigt. Sie enthält die Liste der Compute Nodes, die am Manta Overlay-Netz teilnehmen sollen, sowie die Definition der Netze und die beteiligten MAC-Adressen der besagten Compute Nodes. Die Konfiguration ist im Grunde für alle beteiligten Datacenter/AZs gleich - sie unterscheidet sich nur durch die aufgeführten Compute Nodes. Das Kommando manta-net.sh wird wie in der Anleitung beschrieben ausgeführt.
  • Nachdem die Netzwerkkonfiguration in allen drei Datacentern/AZs ausgebracht worden ist, wird eine Konfiguration für das Deployment benötigt. Wie diese erzeugt werden kann, habe ich in "Distributed Manta - Planen und Konfigurieren" beschrieben. Ergebnis ist je eine Konfigurationsdatei pro Datacenter/AZ.
  • Im nächsten Schritt werden die einzelnen Punkte des Manta-Deployments durchlaufen. Sie sind dem Skript manta-deploy-dev entnommen.
    • Zunächst muss manta-init im Primary-DC durchgeführt werden. Es darf auf keinen Fall in den Secondary-DCs ausgeführt werden. Mit diesem Kommando wird der User poseidon angelegt und es werden die erforderlichen Manta-Images heruntergeladen. Der aktuelle Bearbeitungsstand lässt sich im angegebenen Logfile mitverfolgen. Am längsten dürfte der Download des Marlin-Images dauern, dass derzeit ca. 17 GB groß ist.
    • Nachdem dieser Schritt abgeschlossen ist, kann im Primary-DC der Hash-Ring erzeugt werden. Ich empfehle, die Werte der "lab"-Konfiguration zu übernehmen: manta-create-topology.sh -v 10000000 -p 2020. 
    • Während dies durchläuft, müssen in den Secondary-DCs die Manta-Images heruntergeladen und der poseidon User als Besitzer für die Netze "admin", "manta" und "mantanat" hinzugefügt werden. Download und Import der Manta-Images habe ich in "Images importieren" beschrieben. Um welche Images es geht, kann man im Primary-DC ermitteln:
[root@headnode (de-gt-4) ~]# imgadm avail |grep  manta | grep master
05726737-917f-43d2-97a7-8b55d85cddf9  manta-marlin                    master/16.1.0                                     smartos  zone-dataset  2016-08-12
8d97b188-9d92-11e7-8c45-b76cc44484f0  manta-nameservice               master-20170919T232319Z-gb136622                  smartos  zone-dataset  2017-09-19
917f4e96-9d92-11e7-afa9-efbc75fffced  manta-madtom                    master-20170919T232545Z-g74f7418                  smartos  zone-dataset  2017-09-19
c5a6bd70-9d93-11e7-99ad-b3073328879c  manta-storage                   master-20170919T233349Z-g838ab1b                  smartos  zone-dataset  2017-09-19
bf6b251c-9d94-11e7-b89c-f76b5f7fbca9  manta-marlin-dashboard          master-20170919T234202Z-g9cae708                  smartos  zone-dataset  2017-09-19
fd33ab8e-9d95-11e7-8576-7ff70ccd8d98  manta-medusa                    master-20170919T234916Z-g7b01c12                  smartos  zone-dataset  2017-09-19
27c20e80-9d97-11e7-b06a-c32aa10ff698  manta-jobsupervisor             master-20170919T234226Z-gb8af6a8                  smartos  zone-dataset  2017-09-20
7fa7bb86-9d97-11e7-91d7-73c794eb6360  manta-authcache                 master-20170919T233646Z-g75ac3ca                  smartos  zone-dataset  2017-09-20
b9417f4e-9d97-11e7-8aeb-43581a010132  manta-ops                       master-20170919T235820Z-g94b1e89                  smartos  zone-dataset  2017-09-20                                            
d2ca0b66-9d97-11e7-87a2-6744adfd03b4  manta-loadbalancer              master-20170919T235445Z-g66b2bf1                  smartos  zone-dataset  2017-09-20                                            
bf961b3c-9d99-11e7-bc5a-2b0db2dfae41  manta-jobpuller                 master-20170920T001026Z-g95b5f73                  smartos  zone-dataset  2017-09-20                                            
0d87374a-9d9a-11e7-a3a4-7bd0fa6eda96  manta-propeller                 master-20170920T001755Z-gaebdfa0                  smartos  zone-dataset  2017-09-20                                            
d4026546-b435-11e7-8638-a38565ec99df  manta-postgres                  master-20171018T184133Z-g420f48b                  smartos  zone-dataset  2017-10-18                                            
784f42c6-c350-11e7-b5ad-ef1f13ff334d  manta-webapi                    master-20171107T000659Z-g5aabef1                  smartos  zone-dataset  2017-11-07                                            
8c1d541e-c350-11e7-a191-77eadddb4f51  manta-moray                     master-20171107T000808Z-g44a6fd4                  smartos  zone-dataset  2017-11-07                                            
042b1260-c352-11e7-9665-0b9551a38415  manta-electric-moray            master-20171107T001921Z-gbfd1aa5                  smartos  zone-dataset  2017-11-07                                            
8d350056-ce61-11e7-acff-efb26e69b3f4  manta-electric-moray            master-20171121T020752Z-gc5128f0                  smartos  zone-dataset  2017-11-21                                            
72008406-d526-11e7-9d43-93b1d7fd3026  manta-webapi                    master-20171129T165047Z-gb857270                  smartos  zone-dataset  2017-11-29                                            
c8c66ae6-d6be-11e7-8718-3b4214cd71a4  manta-webapi                    master-20171201T173412Z-g90d57d8                  smartos  zone-dataset  2017-12-01                                            
e528fc84-d6ec-11e7-b023-9bf87a3a9723  manta-authcache                 master-20171201T230631Z-gf5ad52f                  smartos  zone-dataset  2017-12-01                                            
60c3b0b8-d946-11e7-90b6-27b40e74015d  manta-moray                     master-20171204T225105Z-gf761c37                  smartos  zone-dataset  2017-12-04                                            
8b885852-d947-11e7-a159-af1c2e258b53  manta-electric-moray            master-20171204T225923Z-gc5128f0                  smartos  zone-dataset  2017-12-04

Als nächstes ist es sinnvoll, mit manta-sharadm im Primary-DC zu bestimmen welche Shards für welche Bereiche zuständig sind. Die aktuelle Konfiguration sieht so aus:

[root@fb94b510-640b-4357-b636-933deb0799f3 (de-gt-4:manta0) ~]# manta-shardadm list               
TYPE         SHARD NAME                         
Index        1.moray.de-gt.srv.tgos.de          
Index        2.moray.de-gt.srv.tgos.de          
Marlin       1.moray.de-gt.srv.tgos.de          
Storage      3.moray.de-gt.srv.tgos.de
  • Die Anzahl der Shards sollte natürlich der Zahl entsprechen, die man vorher beim Generieren des Manta-Layouts auch angegeben hat.
  • Im nächsten Schritt sollten zunächst die Nameservice-Zonen im Primary-DC ausgerollt werden. Danach die Nameservice-Zonen in den Secondary-DCs. Dazu muss man natürlich die relevanten Konfigurationsdateien in die Manta-Zonen der Secondary-DCs kopiert haben: manta-adm update -y <Konfigurationsdatei> nameservice. Wenn die Zonen problemlos ausgerollt werden, sollte manta-adm zk list ungefähr so aussehen:
[root@fb94b510-640b-4357-b636-933deb0799f3 (de-gt-4:manta0) ~]# manta-adm zk list
# DATACENTER ZONENAME                             IP                PORT                          
1 de-gt-4    d783fb34-4c66-4e1a-b0f9-0439e9de45fb 172.27.4.17       2181                          
2 de-gt-4    8c736f9a-4e55-470f-95e5-c363efb6cdc7 172.27.4.18       2181                          
3 de-gt-1    9ed56abb-5883-4ca6-b2e4-69f25464ba08 172.27.3.10       2181
[root@fb94b510-640b-4357-b636-933deb0799f3 (de-gt-4:manta0) ~]#
    • Es ist angeraten, den Zustand der Nameservice-Zonen auf den jeweiligen Compute Nodes noch mit svcs -Zxv zu überprüfen. Wenn keine Services in Maintenance oder Offline sind, sollte das Setup funktionieren.
    • Danach kann das Deployment mit manta-adm update -y <Konfigurationsdatei> komplett durchgeführt werden. Es sollten keine Deployment parallel durchgeführt werden. Erst im Primary-DC, dann im ersten Secondary-DC, dann im zweiten Secondary-DC.
    • Spätestens nach dem Deployment der webapi kann man dann noch die Variable MUSKIE_MULTI_DC auf true setzen, wie in "AZ-Kopplung bei Triton" beschrieben.
    • Zum Schluss muss noch der marlin-agent auf die Compute Nodes mit den Marlin-Zonen ausgebracht werden. Das geschieht mit manta-marlin - wie im manta-deployment-dev beschrieben.
  • Wichtig ist, dass die Compute Nodes, die die Loadbalancer-Zonen beherbergen, auf einem ihrer Netzwerkinterfaces das NIC-Tag "external" konfiguriert haben. Sonst schlägt das Deployment für diese Zonen fehl. 
  • In der Übersicht stellt sich das aktuelle Deployment dann so dar:
[root@fb94b510-640b-4357-b636-933deb0799f3 (de-gt-4:manta0) ~]# manta-adm show -s                 
SERVICE          SH VERSION                                    COUNT
authcache         1 master-20170919T233646Z-g75ac3ca               1                              
electric-moray    1 master-20171107T001921Z-gbfd1aa5               3
jobpuller         1 master-20170920T001026Z-g95b5f73               1                              
loadbalancer      1 master-20170919T235445Z-g66b2bf1               3
marlin            1 master/16.1.0                                192                              
marlin-dashboard  1 master-20170919T234202Z-g9cae708               1
medusa            1 master-20170919T234916Z-g7b01c12               1                              
moray             1 master-20171107T000808Z-g44a6fd4               2
moray             3 master-20171107T000808Z-g44a6fd4               1                               
nameservice       1 master-20170919T232319Z-gb136622               2
postgres          1 master-20171018T184133Z-g420f48b               2                              
postgres          3 master-20171018T184133Z-g420f48b               1
storage           1 master-20170919T233349Z-g838ab1b               3                              
webapi            1 master-20171107T000659Z-g5aabef1               3
[root@fb94b510-640b-4357-b636-933deb0799f3 (de-gt-4:manta0) ~]#


[root@0134c4c9-6474-4a1c-a6f9-2c0c8a32a1d3 (de-gt-1:manta0) ~]# manta-adm show -s
SERVICE          SH VERSION                                    COUNT
authcache         1 master-20170919T233646Z-g75ac3ca               1
electric-moray    1 master-20171107T001921Z-gbfd1aa5               3
jobpuller         1 master-20170920T001026Z-g95b5f73               1
jobsupervisor     1 master-20170919T234226Z-gb8af6a8               1
loadbalancer      1 master-20170919T235445Z-g66b2bf1               3
marlin            1 master/16.1.0                                144
medusa            1 master-20170919T234916Z-g7b01c12               1
moray             1 master-20171107T000808Z-g44a6fd4               1
moray             2 master-20171107T000808Z-g44a6fd4               1
moray             3 master-20171107T000808Z-g44a6fd4               1
nameservice       1 master-20170919T232319Z-gb136622               1
postgres          1 master-20171018T184133Z-g420f48b               1
postgres          2 master-20171018T184133Z-g420f48b               1
postgres          3 master-20171018T184133Z-g420f48b               1
storage           1 master-20170919T233349Z-g838ab1b               3
webapi            1 master-20171107T000659Z-g5aabef1               3
[root@0134c4c9-6474-4a1c-a6f9-2c0c8a32a1d3 (de-gt-1:manta0) ~]#


[root@2fa6a089-e9a4-4238-833d-3d6d319333f0 (de-gt-3:manta0) ~]# manta-adm show -s                 
SERVICE          SH VERSION                                    COUNT                              
electric-moray    1 master-20171107T001921Z-gbfd1aa5               3                              
jobsupervisor     1 master-20170919T234226Z-gb8af6a8               1                              
loadbalancer      1 master-20170919T235445Z-g66b2bf1               3
madtom            1 master-20170919T232545Z-g74f7418               1                              
marlin            1 master/16.1.0                                 32                              
moray             2 master-20171107T000808Z-g44a6fd4               2                              
moray             3 master-20171107T000808Z-g44a6fd4               1                              
ops               1 master-20170919T235820Z-g94b1e89               1                              
postgres          2 master-20171018T184133Z-g420f48b               2                              
postgres          3 master-20171018T184133Z-g420f48b               1                              
storage           1 master-20170919T233349Z-g838ab1b               2                              
webapi            1 master-20171107T000659Z-g5aabef1               3                              
[root@2fa6a089-e9a4-4238-833d-3d6d319333f0 (de-gt-3:manta0) ~]#

Nur zur Dokumentation - die Manta-Dienste werden in der folgenden Reihenfolge ausgerollt:

var mSvcNames = [
    'nameservice',
    'postgres',
    'moray',
    'electric-moray',
    'storage',
    'authcache',
    'webapi',
    'loadbalancer',
    'jobsupervisor',
    'jobpuller',
    'medusa',
    'ops',
    'madtom',
    'marlin-dashboard',
    'marlin'
];

Natürlich sind auch jetzt noch ein paar Fragen offen. So zeigt madtom z. B. noch "rote" Flecken:

Im Moment habe ich noch keine Ursache dafür gefunden, warum die Zonen mit electric-moray in den Secondary Datacentern nicht starten. Der Grund für die "roten" marlin-Agents ist vermutlich eine falsche Konfiguration der Agenten, die von einem früheren Deployment übriggeblieben und noch nicht korrigiert worden ist.

Als Grund dafür, dass sich die electric-moray Zonen in den Secondary Datacentern nicht vollständig deployen lassen liegt darin, dass von dort ein Zugriff auf die imgapi im Primary Datacenter nicht möglich ist. Diese ist durch Firewalleinträge geschützt (was man gut in der adminui erkennen kann). 

Schaltet man die Firewall für die imgapi temporär in der adminui ab, können die electric-moray Zonen erneut ausgerollt werden:

[root@esxp-7336 (de-gt-1) ~]# vmadm list |grep -i elect                                                                                
50a5c8e1-c417-41f0-82c9-fc7b2bdbde05  OS    3072     running           electric-moray.de-gt.mydc.internal-50a5c8e1
[root@esxp-7336 (de-gt-1) ~]# vmadm get 50a5c8e1-c417-41f0-82c9-fc7b2bdbde05 > /var/tmp/electric.json
[root@esxp-7336 (de-gt-1) ~]# vmadm reprovision 50a5c8e1-c417-41f0-82c9-fc7b2bdbde05 -f /var/tmp/electric.json

Das Problem der "roten" marlin-Agents hatte sich gelöst, nachdem die entsprechenden CNs neu installiert waren. Damit sieht das Monitoring dann so aus:

Share