Piszki Lab

Analiza przypadku w języku przodków…

CloudStack – instalacja i konfiguracja, część 3, przygotowanie węzła.

| 2 komentarze

W poprzednich częściach zapoznaliśmy się z terminologią CloudStack i z konfiguracją sieci na węzłach. W tym poście skupimy się na przygotowaniu węzłów do pełnienia roli serwera wirtualizacji oraz poczynimy pierwsze kroki w konfiguracji środowiska zarządczego. Niestety, w między czasie musiałem oddać fizyczne serwery, dlatego dalszy ciąg będzie opisany na podstawie trzech wirtualnych maszyn uruchomionych pod ESXi. O tym jak przygotować zagnieżdżony serwer KVM w VMware vSphere pisałem tutaj, różnica jest tylko jedna, jako że będziemy stawiać CloudStack z siecią zaawansowaną (VLAN), zagnieżdżony KVM musi być przypięty do port grupy typu Trunk (dla sieci CloudStack). Będzie to długi i nudny wpis, ale bez niego nie da rady iść dalej.

Bazujemy na systemie CentOS 7, najlepiej jest aby wszystkie węzły miały ten sam zestaw pakietów. W poprzednim artykule instalowane były pakiety potrzebne do kompilacji i instalacji OpenvSwitch, teraz doinstalujemy wszystko to, co będzie nam potrzebne. Zaczynamy od stworzenia właściwych plików repo:

/etc/yum.repos.d/CloudStack.repo

[cloudstack-4.10]
name=cloudstack
baseurl=http://cloudstack.apt-get.eu/centos/7/4.10/
enabled=1
gpgcheck=0
gpgkey=http://cloudstack.apt-get.eu/release.asc

/etc/yum.repos.d/MariaDB.repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

 /etc/yum.repos.d/Ceph.repo

[Ceph]
name=Ceph packages for $basearch
baseurl=http://download.ceph.com/rpm-luminous/el7/$basearch
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://download.ceph.com/keys/release.asc

Instalujemy potrzebne pakiety:
yum install nano bash-completion mc net-tools wget curl bind-utils lsof rpcbind nfs-utils scree bmon epel-release ntp keepalived haproxy rsync nmap perl-Dbi nc socat jemalloc xinetd galera mariadb-server mariadb-client kvm libvirt virt-install virt-manager qemu-kvm libvirt-client virt-viewer bridge-utils qemu-img libvirt-python xauth cloudstack-agent cloudstack-management cloudstack-usage

Każdy węzeł będzie pełnił wiele ról, będzie członkiem klastra MariaDB-Galera, członkiem klastra CloudStack, serwerem KVM oraz członkiem klastra Ceph (dlatego możemy zainstalować wszystkie pakiety od razu). Dlaczego Ceph? Dlatego że potrzebujemy współdzielonej, klastrowanej przestrzeni dyskowej, bez niego nie będzie możliwe przenoszenie maszyn pomiędzy hostami (vMotion). Oczywiście wspierane są też dyski lokalne w CloudStack, niestety tutaj jesteśmy zamknięci w jednym hoście. A my chcemy postawić konfigurację zaawansowaną, przypominającą funkcjonalnie VMware vSphere.

Wróćmy do storage, CloudStack potrzebuje wejściowo dwóch przestrzeni, Primary Storage i Secondary Storage. Primary pełni rolę głównej, współdzielonej przestrzeni a Secondary jest udziałem NFS. W obydwu przypadkach wykorzystamy Ceph (można też GlusterFS jeśli mamy mniej niż 3 węzły), CloudStack jako jedyne znane mi rozwiązanie (typu Open Source) wspiera SharedMountPoint, jest to lokalnie zamontowana przestrzeń dyskowa dostępna bezpośrednio na każdym węźle z poziomu systemu plików. Oznacza to, że tak jak w VMware, mamy dostęp fizyczny do pliko dysków maszyn wirtualnych (które leżą sobie we współdzielonym katalogu). Można też Ceph montować jako udział RBD (blokowy) i jest to metoda preferowana dla sieci 10GB, jeśli konfiguracja jaką stawiamy idzie po sieci 1GB to zróbmy to jako CephFS (osiągniemy większą wydajność niż RBD po 1GB) ze względu na możliwość użycia profilu cache (WriteBack) na poziomie CloudStack (zapis buforuje się w pamięci ram). Secondary Storage wystawimy jako udział CephFS po NFS na każdym węźle, dostęp będzie poprzez pływający adres IP hostowany przez KeepaliveD (można też poprzez Ganesha NFS lub montować ze zdalnego serwer NFS, np. z NAS).

Kontynuujemy przygotowanie węzła (na każdym węźle te ustawienia są takie same), zaczniemy od systemu. Do poprawnego działania sieci wewnątrz serwerów KVM należy odpowiednio dostroić parametry jądra systemu, robimy to za pomocą zawartości pliku /etc/sysctl.conf :

net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
fs.file-max = 100000

W przypadku SELinux i FirewallD, proponuję wyłączyć i dostroić do własnych potrzeb po poprawnym uruchomieniu całości. W kolejnym kroku konfigurujemy KVM (zmieniamy podane parametry w podanych plikach konfiguracyjnych). Włączamy nasłuchiwanie na porcie 16509 w ruchu nieszyfrowanym i nie autentykowanym (wymaganie podstawowe CloudStack):

/etc/libvirtd/libvird.conf:

listen_tcp=1
listen_tls=1
tcp_port=”16509”
mdns_adv=0
auth_tcp=”none”

Dla CloudStack 4.11 i wyżej wymagane jest połączenie szyfrowane (nawet jeśli wyłączymy wbudowany w CloudStack CA i autentykację SSL). CloudStack Agent sam zmodyfikuje odpowiednio ww. plik.

Nasłuchiwanie konsoli VNC:

/etc/libvirtd/qemu.conf:
vnc_listen=0.0.0.0

Nasłuchiwanie libvirtd (-l to odpowiednik –listen).

/etc/sysconfig/libvirtd:
LIBVIRTD_ARGS=-l

Zmiany aktywujemy poprzez restart usługi libvirtd lub hosta. W pliku konfiguracyjnym /etc/cloudstack/agent/agent.properties zmieniamy następujące opcje:

network.bridge.type=openvswitch
libvirt.vif.driver=com.cloud.hypervisor.kvm.resource.OvsVifDriver

Dopisujemy linie:

guest.cpu.model=SandyBridge (lub zgodne z naszą architekturą)
guest.cpu.mode=custom

Powyższe ustawienia są dobre, jeśli mamy hosty o różnych procesorach (w ramach jednej architektury) i musimy uzgodnić zestaw instrukcji w ramach którego będą funkcjonować VM (aby umożliwić vMotion). Sprawdzenie jakie procesory są u nas obsługiwane: virsh cpu-models x86_64

Jeśli wszystkie hosty mają tę samą architekturę (dotyczy to fizyki ale i vm z KVM) to ustawiamy tam parametr (zapewni to najwyższą możliwą wydajność):

guest.cpu.mode=host-passthrough

Standardowe mostki sieciowe (instalowane z KVM) wchodzą w interakcję z OpenvSwitch, należy zablokować moduł jądra odpowiedzialny za ich obsługę.

Tworzymy plik /etc/modprobe.d/blacklist.conf z zawartością „blacklist bridge”.

Przypomnijmy, na tym etapie mamy trzy (wirtualne w moim przypadku) serwery przygotowane do pełnienia wielu ról wraz ze skonfigurowaną siecią. Budujemy środowisko odporne na awarie, HA w CloudStack oprzemy na KeepaliveD i HAProxy. CloudStack nie wspiera MariaDB-Galera wprost, dlatego będzie się z nią łączył poprzez pływający adres IP który będzie także punktem wejścia dla usługi NFS, do połączeń CloudStack Agent oraz do łączenia się z interfejsem WEB CloudStack Managemen Server (oczywiście jeśli stawiacie CloudStack na pojedynczej maszynie to nie potrzebujecie ani klastra Galery ani Ceph i w zasadzie możecie pominąć dalszą część posta). Dla każdego IP tworzymy rekord DNS, w moim przypadku będzie to:

cstack.piszki.lab – 192.168.70.70 (IP pływający)
cstack-1.piszki.lab – 192.168.70.71 (węzeł 1)
cstack-2.piszki.lab – 192.168.70.72 (węzeł 2)
cstack-3.piszki.lab – 192.168.70.73 (węzeł 3)

Jako że każdy węzeł jest równy, nie będzie powrotu na stary serwer po jego ponownym uruchomieniu po awarii (usługi przeskoczą i zostaną na nowym serwerze). Ostatecznie z tego pomysłu zrezygnowałem, pierwszy węzeł jest tym równiejszym (head node) i na niego wrócą wszystkie usługi gdy wstanie. Ma to wiele zalet, np. jest też serwerem Ceph Admin, Ansible, itp itd, logując się poprzez pływający IP zawsze będziemy mieli pod ręką wszystkie narzędzia administracyjne.

Konfiguracja KeepaliveD (dla KVM działającego jako wirtualna maszyna należy zastosować opcje unicast), cstack-1:

global_defs {
   router_id CS_LAB
}

vrrp_script haproxy {
script "/usr/bin/killall -0 haproxy"
interval 2
weight 2
}

vrrp_instance CS_1 {
    state MASTER
    interface cloudbr0
    virtual_router_id 231
    priority 100
    unicast_src_ip 192.168.70.71
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.70.70/24
    }
    unicast_peer {
        192.168.70.72
    }
    track_script {
    haproxy
    }
}

Konfiguracja dla drugiego noda, cstack-2:

global_defs {
router_id CS_LAB
}

vrrp_script haproxy {
script "/usr/bin/killall -0 haproxy"
interval 2
weight 2
}

vrrp_instance CS_1 {
    state MASTER
    interface cloudbr0
    virtual_router_id 231
    priority 50
    unicast_src_ip 192.168.70.72
    authentication {
       auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
    192.168.70.70/24
    }
    unicast_peer {
    192.168.70.71
    }
    track_script {
    haproxy
    }
}

Konfiguracja ta obsługuje usługę MariaDB-Galera (za pomocą skryptu clustercheck o czym będzie niżej) oraz dostęp do usługi CloudStack Management Server (po http i https). Czas najwyższy uruchomić sam klaster Galery, jest to bardzo proste. Tworzymy na każdym węźle właściwy plik /etc/my.cnf.d/server.conf (tutaj macie mój, zajmie co najmniej 4GB RAM):

[server]
[mysqld]
bind-address = 0.0.0.0
binlog_format = ROW
character_set_server = utf8
collation_server = utf8_general_ci
datadir = /var/lib/mysql
default_storage_engine = InnoDB
expire_logs_days = 10
innodb_autoinc_lock_mode = 2
innodb_buffer_pool_size = 512M
innodb_log_file_size = 1024M
innodb_doublewrite = 1
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 600
innodb_stats_on_metadata = 0
key_buffer_size = 128M
lock_wait_timeout = 300
max_allowed_packet = 1G
max_statement_time = 100
max_binlog_size = 64M
max_connections = 500
myisam_sort_buffer_size = 32M
net_buffer_length = 8K
query_cache_limit = 32M
query_cache_size = 64M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
skip-external-locking
sort_buffer_size = 8M
table_cache = 2048
table_definition_cache = 32345
table_open_cache = 32345
thread_cache_size = 100
log_error = /var/log/mariadb/mariadb_error.log
log_warnings = 1
#general_log_file = /var/log/mariadb/mariadb.log
#general_log = 1

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.70.71,192.168.70.72,192.168.70.73"
wsrep_cluster_name="cloudstack_db"
wsrep_node_name="H1"
wsrep_node_address="192.168.70.71"
#wsrep_sst_method=rsync
#wsrep_sst_auth=sst_user:dbpass
[embedded]
[mariadb]
[mariadb-10.1]
[mysqldump]
max_allowed_packet = 16M
quick
quote-names
[mysql]
[isamchk]
key_buffer = 256M
read_buffer = 16M
sort_buffer_size = 256M
write_buffer = 16M

Na każdym węźle poprawiamy node_name i node_address i uruchamiamy na pierwszym węźle poleceniem galera_new_cluster (wystartowanie nowego klastra jest potrzebne zawsze gdy wyłączone będą wszystkie węzły). Na pozostałych startujemy standardowo systemctl start/enable mariadb i dalej mysql_secure_installation (w tym przykładzie hasło na root db ustawiamy na dbpass).

Teraz skonfigurujemy skrypt clustercheck:

wget https://raw.githubusercontent.com/olafz/percona-clustercheck/master/clustercheck

chmod +x clustercheck
mv clustercheck /usr/bin/

vi /etc/xinetd.d/mysqlchk

# default: on
# description: mysqlchk
service mysqlchk
{
        disable = no
        flags = REUSE
        socket_type = stream
        port = 9200             # This port used by xinetd for clustercheck
        wait = no
        user = nobody
        server = /usr/bin/clustercheck
        log_on_failure += USERID
        log_on_success =
        only_from = 0.0.0.0/0
        per_source = UNLIMITED
}

vi /etc/services

mysqlchk        9200/tcp                # mysqlchk
#wap-wsp         9200/tcp                # WAP connectionless session service
#wap-wsp         9200/udp                # WAP connectionless session service

systemctl start/enable xinetd

mysql -u root -p
GRANT PROCESS ON *.* TO ‘clustercheckuser’@’localhost’ IDENTIFIED BY ‘clustercheckpassword!’ ;
exit;

Testy (jeśli macie błąd, to sprawdźcie w skrypcie clustercheck czy prawidłowo podany jest użytkownik i hasło):

[root@cstack-2 ~]# /usr/bin/clustercheck
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Content-Length: 40

Percona XtraDB Cluster Node is synced.

W kolejnym kroku konfigurujemy HAProxy:

global
log         127.0.0.1 local2

chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     4000
user        haproxy
group       haproxy
daemon

stats socket /var/lib/haproxy/stats

defaults
mode                    http
log                     global
option                  tcplog
option                  dontlognull
option http-server-close
option                  redispatch
retries                 3
timeout http-request    10s
timeout queue           1m
timeout connect         10s
timeout client          1m
timeout server          1m
timeout http-keep-alive 10s
timeout check           10s
maxconn                 3000

listen mariadb_cluster 0.0.0.0:3030
mode tcp
balance leastconn
server cstack-1:3306 192.168.70.71:3306 check port 9200
server cstack-2:3306 192.168.70.72:3306 check port 9200 backup
server cstack-3:3306 192.168.70.73:3306 check port 9200 backup

listen stats 0.0.0.0:9000
mode http
stats enable
stats uri /stats
stats realm HAProxy\ Statistics
stats auth admin:admin
stats admin if TRUE

frontend ui
        bind 192.168.70.70:80
        mode http
        option forwardfor
        option httplog
        use_backend uib

frontend uis
        bind 192.168.70.70:443 ssl crt /etc/haproxy/cloud.pem
        mode http
        option httpclose
        option forwardfor
        reqadd X-Forwarded-Proto:\ https
        use_backend uib

backend uib
        option httpchk OPTIONS /client
        balance source
        server cstack-1:8080 192.168.70.71:8080 maxconn 32 check
        server cstack-2:8080 192.168.70.72:8080 maxconn 32 check backup
Testy:

mysql -u root -p
GRANT ALL PRIVILEGES ON *.* TO root@’%’ IDENTIFIED BY “dbpass”;

mysql -u root -p -h 192.168.70.X -P 3030 -e “select Host, User, Password from mysql.user”

Włączenie logowania HAProxy (dla rsyslogd), plik /etc/rsyslog.d/haproxy.conf:

local2.* /var/log/haproxy.log
local2.=info /var/log/haproxy-info.log
local2.notice /var/log/haproxy-allbutinfo.log

Dzięki takiej konfiguracji uzyskaliśmy klaster MariaDB-Galera dostępny na porcie 3030 poprzez każdy adres IP (w tym najważniejszy, pływający), każde połączenie jest balansowane przez HAProxy pomiędzy wszystkimi węzłami. Taka konfiguracja zabezpieczy CloudStack Management Server przed awariami węzłów. Dodatkowo mamy podgląd na pracę HAProxy pod adresem http://192.168.70.70:9000/stats. Na tę chwilę zostawimy Galerę i przejdziemy do Ceph. Instalacja i uruchomienie Ceph jest bardzo proste, musimy jedynie spełnić podstawy warunek, minimum trzy serwery i minimum jeden dysk per serwer przeznaczony pod pulę dyskową. Można zmusić Ceph do uruchomienia na jednym i dwóch węzłach ale to już jest dłubanie i pozostawiam to Wam (możecie też zastosować GlusterFS 1:1).

Na wybranym węźle który będzie pełnił rolę Admin Server dla Ceph instalujemy pakiet ceph-deploy (a na każdym ceph-fuse). Dodatkowo dla użytkownika który będzie pełnił rolę Admin Ceph (np. root) generujemy klucz ssh (ssh-keygen z pustym hasłem) i rozsyłamy go poleceniem ssh-copy-id na pozostałe węzły. Rezultat jaki musimy osiągnąć to możliwość zalogowania się po ssh bez hasła na każdy węzeł. Tworzymy też plik (uprawnienia 644):

[root@cstack-1 .ssh]# cat config

Host cstack-1
Hostname cstack-1
User root
Host cstack-2
Hostname cstack-2
User root
Host cstack-3
Hostname cstack-3
User root

Następnie wydajemy polecenie (najlepiej w jakimś katalogu a nie w katalogu domowym użytkownika):

ceph-deploy new cstack-1 cstack-2 cstack-3

W ten sposób uzyskamy inicjalną konfigurację Ceph, modyfikujemy plik ceph.conf do postaci jaka nas interesuje (tutaj mój):

[root@cstack-1 ceph]# cat ceph.conf

[global]
fsid = 9d9d1a99-c5f0-4b93-acca-37245488002d
mon_initial_members = cstack-1, cstack-2, cstack-3
mon_host = 192.168.70.71,192.168.70.72,192.168.70.73
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
osd_pool_default_size = 2
osd_pool_default_min_size = 2
osd pool default pgp num = 256
osd pool default pg num = 256
osd max object name len = 256
osd max object namespace len = 64
mon_allow_pool_delete = True
#public network = 192.168.70.0/24
#cluster network = 172.18.37.0/24

[osd]
osd mkfs options xfs = -f -i size=2048
osd mkfs type = xfs
osd journal size = 5120
osd mount options xfs = noatime,largeio,inode64,swalloc

Zmienne public network i cluster network definiują nam sieci którymi Ceph udostępnia i wymienia pomiędzy węzłami dane. Nie są obligatoryjne, jeśli ich nie użyjemy to cała komunikacja pójdzie głównym interfejsem sieciowym maszyny (zalecane jest jednak aby szło to osobnymi interfejsami). Następnie wykonujemy polecenie:

ceph-deploy install cstack-1 cstack-2 cstack-3


(można ją ponawiać np. dla wybranego serwera gdy coś będzie nie tak). Jeśli instalacja wykonała się poprawnie, wykonujemy polecenie:

ceph-deploy mon create-initial


(roześlemy konfigurację do węzłów). Teraz wydajemy polecenie:

ceph-deploy gatherkeys cstack-1

ceph-deploy admin cstack-1 cstack-2 cstack-3


(roześlemy klucz administracyjny umożliwiający działanie polecenia ceph, np. ceph –w do monitorowania stanu klastra) i na końcu:

ceph-deploy mgr create cstack-1 cstack-2 cstack-3


Na tym etapie mamy działający klaster Ceph bez podłączonych dysków (OSD). Przygotowanie i aktywowanie dysków jest równie proste, u mnie pod OSD idą dyski sdb, wykonujemy polecenie (dla Ceph Luminous i nowszych z fs bluestore):

ceph-deploy osd prepare –bluestore –block-db /dev/sdb –block-wal /dev/sdb cstack-2:sdb

ceph-deploy osd activate cstack-2:sdb1

Dla wersji Mimic i nowszych: ceph-deploy osd create --data /dev/sdb cstack-2 (dla każdego hosta, per dysk)

Testy:

[root@cstack-1 ceph]# ceph osd tree
ID CLASS WEIGHT  TYPE NAME        STATUS REWEIGHT PRI-AFF
-1       0.29095 root default
-3       0.09698     host cstack-1
0   hdd 0.09698         osd.0        up  1.00000 1.00000
-5       0.09698     host cstack-2
1   hdd 0.09698         osd.1        up  1.00000 1.00000
-7       0.09698     host cstack-3
2   hdd 0.09698         osd.2        up  1.00000 1.00000
[root@cstack-1 ceph]# ceph -s
cluster:
id:     b1bf8ac2-d9b6-486c-9ca5-6abd59e6d20e
health: HEALTH_OK

services:
mon: 3 daemons, quorum cstack-1,cstack-2,cstack-3
mgr: cstack-1(active), standbys: cstack-3, cstack-2
osd: 3 osds: 3 up, 3 in

data:
pools:   0 pools, 0 pgs
objects: 0 objects, 0 bytes
usage:   6149 MB used, 292 GB / 298 GB avail
pgs:

Czyli mamy działający klaster Ceph, trzy węzły, trzy dyski, trzy monitory. To nie koniec, dla CephFS musimy jeszcze uruchomić MetaDadata Server, stworzyć FS i zamontować go lokalnie na każdym serwerze. Jeśli wielkość 128 jest zbyt duża dla Was (komunikat o błędzie) to dopasujcie ją do wielkości dysku zmniejszając odpowiednio podane wartości.

ceph-deploy mds create cstack-1 cstack-2 cstack-3

ceph osd pool create cephfs_data 128

ceph osd pool create cephfs_metadata 128

ceph fs new cephfs cephfs_metadata cephfs_data

Testy:

[root@cstack-1 ceph]# ceph mds stat
cephfs-1/1/1 up  {0=cstack-3=up:active}, 2 up:standby

Teraz pozostaje zamontować wolumen cephfs lokalnie na każdym węźle, jest wiele metod, najprostsza to /etc/fstab (cp /etc/ceph/ceph.client.admin.keyring /etc/ceph.key chmod 644 /etc/ceph.key w samym pliku należy pozostawić jedynie wartość klucza):

192.168.70.71:6789:/            /data           ceph            name=admin,secretfile=/etc/ceph.key,_netdev,noatime     0 2

W CentOS 7 (w innych systemach też) możemy montować udział w formie usługi SystemD, jest to metoda preferowana o ile mamy usługi zależne od zamontowania udziału. A taką jest np. CloudStack Agent, dzięki temu wszystko można poustawiać w odpowiedniej kolejności aby w trakcie systemu nie było problemów.

Na końcu będziemy potrzebowali udziału NFS, udział ten będzie wykorzystywany przez maszynę systemową CloudStack Secondary Storage VM i służy do przechowywania template maszyn systemowych (routery wirtualne), template maszyn które zrobicie i snapshotów. Można użyć dowolnego serwera NFS (np. NAS), ja uruchomię lokalnie na każdym węźle serwer NFS dla katalogu /data/nfs a montować udział będę poprzez pływający adres IP. Dzięki temu awaria jednego z węzłów nie spowoduje niedostępności serwera NFS (taką samą funkcjonalność daje Ganesha NFS). Uruchamiamy potrzebne usługi:

systemctl enable rpcbind
systemctl enable nfs-server
systemctl enable nfs-lock
systemctl enable nfs-idmap
systemctl start rpcbind
systemctl start nfs-server
systemctl start nfs-lock
systemctl start nfs-idmap

I robimy wpis w pliku /etc/exports:

/data/nfs       192.168.70.0/24(rw,sync,no_root_squash,no_all_squash)

Na koniec uwagi o optymalizacji. Nigdzie wcześniej nie pisałem o DNS i NTP, ale to oczywista oczywistość, zsynchronizowane czasowo nody to dla MariaDB Galera i Ceph coś bez czego usługi się rozłożą. W CentOS 7 mamy domyślnie zainstalowaną i uruchomioną usługę dynamicznego tuningu KSM. Warto sprawdzić (tuned-adm active) jaki mamy profil aktywny i dla hosta zmienić go na virtual-host (nawet jeśli jest to zagnieżdżony, wirtualny KVM). Warto wyłączyć splash screen w trakcie boottowania systemu (usuwamy rhgb quiet) oraz włączyć obsługę IOMMU (nawet w wirtualnym KVM), robimy to w /etc/default/grub:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolumeGroup/lvm_root nouveau.modeset=0 rd.driver.blacklist=nouveau plymouth.ignore-udev intel_iommu=on"

Warto sprawdzić czy spełniamy wszystkie warunki dla poprawnej i wydajnej pracy KVM poleceniem: virt-host-validate

I to w tym poście na tyle. Dużo pracy trzeba wykonać ale jest ona niezbędna aby później na poziomie CloudStack uniknąć problemów. Dobrze przygotowany węzeł to podstawa. W kolejnym poście uruchomimy CloudStack i wykonamy inicjalną konfigurację. Mam nadzieję że jeszcze się nie zniechęciliście, tak na prawdę, przy odrobinie wprawy całość instalacji i konfiguracji sporego środowiska zajmuje dzień maksymalnie dwa. Jak do tego dołożymy Ansible to postawienie CloudStack zajmuje chwilę.

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

2 Comments

  1. Ekstra mikro przewodnik. Warto by dodać ze przy tworzeniu cepfs-a używanie takiej samej liczby PGs dla metadanych i samych danych jest rozrzutnością :)
    Ratio 1:4 w zupełności wystarczy.

    Link do źródła :
    https://ceph.com/planet/cephfs-ideal-pg-ratio-between-metadata-and-data-pools/

    • Kurcze jednak ktoś to czyta :-)
      Dzięki za podpowiedź, na horyzoncie mam uruchomienie pierwszej produkcyjnej instalacji Ceph, muszę się doszkolić w tym temacie.
      Generalnie temat CloudStack popchnąłem tak daleko do przodu, że czas wydać kolejne części poradnika ;-)

      Piotr

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.