{"id":3446,"date":"2018-01-08T09:50:03","date_gmt":"2018-01-08T08:50:03","guid":{"rendered":"https:\/\/vm.piszki.pl\/?p=3446"},"modified":"2019-01-03T09:06:06","modified_gmt":"2019-01-03T08:06:06","slug":"cloudstack-instalacja-i-konfiguracja-czesc-3-przygotowanie-wezla","status":"publish","type":"post","link":"https:\/\/vm.piszki.pl\/?p=3446","title":{"rendered":"CloudStack – instalacja i konfiguracja, cz\u0119\u015b\u0107 3, przygotowanie w\u0119z\u0142a."},"content":{"rendered":"

W poprzednich cz\u0119\u015bciach zapoznali\u015bmy si\u0119 z terminologi\u0105 CloudStack i z konfiguracj\u0105 sieci na w\u0119z\u0142ach. W tym po\u015bcie skupimy si\u0119 na przygotowaniu w\u0119z\u0142\u00f3w do pe\u0142nienia roli serwera wirtualizacji oraz poczynimy pierwsze kroki w konfiguracji \u015brodowiska zarz\u0105dczego. Niestety, w mi\u0119dzy czasie musia\u0142em odda\u0107 fizyczne serwery, dlatego dalszy ci\u0105g b\u0119dzie opisany na podstawie trzech wirtualnych maszyn uruchomionych pod ESXi. O tym jak przygotowa\u0107 zagnie\u017cd\u017cony serwer KVM w VMware vSphere pisa\u0142em tutaj<\/a>, r\u00f3\u017cnica jest tylko jedna, jako \u017ce b\u0119dziemy stawia\u0107 CloudStack z sieci\u0105 zaawansowan\u0105 (VLAN), zagnie\u017cd\u017cony KVM musi by\u0107 przypi\u0119ty do port grupy typu Trunk (dla sieci CloudStack). B\u0119dzie to d\u0142ugi i nudny wpis, ale bez niego nie da rady i\u015b\u0107 dalej.<\/p>\n

Bazujemy na systemie CentOS 7, najlepiej jest aby wszystkie w\u0119z\u0142y mia\u0142y ten sam zestaw pakiet\u00f3w. W poprzednim artykule instalowane by\u0142y pakiety potrzebne do kompilacji i instalacji OpenvSwitch, teraz doinstalujemy wszystko to, co b\u0119dzie nam potrzebne. Zaczynamy od stworzenia w\u0142a\u015bciwych plik\u00f3w repo:<\/p>\n

\/etc\/yum.repos.d\/CloudStack.repo<\/span><\/p>\n

[cloudstack-4.10]<\/span>\r\nname=cloudstack<\/span>\r\nbaseurl=http:\/\/cloudstack.apt-get.eu\/centos\/7\/4.10\/<\/span>\r\nenabled=1<\/span>\r\ngpgcheck=0<\/span>\r\ngpgkey=http:\/\/cloudstack.apt-get.eu\/release.asc<\/span><\/pre>\n
\/etc\/yum.repos.d\/MariaDB.repo<\/span><\/p>\n
[mariadb]<\/span>\r\nname = MariaDB<\/span>\r\nbaseurl = http:\/\/yum.mariadb.org\/10.1\/centos7-amd64<\/span>\r\ngpgkey=https:\/\/yum.mariadb.org\/RPM-GPG-KEY-MariaDB<\/span>\r\ngpgcheck=1<\/span><\/pre>\n
\u00a0<\/span>\/etc\/yum.repos.d\/Ceph.repo<\/span><\/p>\n
[Ceph]<\/span>\r\nname=Ceph packages for $basearch<\/span>\r\nbaseurl=http:\/\/download.ceph.com\/rpm-luminous\/el7\/$basearch<\/span>\r\nenabled=1<\/span>\r\ngpgcheck=1<\/span>\r\ntype=rpm-md<\/span>\r\ngpgkey=https:\/\/download.ceph.com\/keys\/release.asc<\/span><\/pre>\n
Instalujemy potrzebne pakiety:
\nyum 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<\/span><\/p>\n
Ka\u017cdy w\u0119ze\u0142 b\u0119dzie pe\u0142ni\u0142 wiele r\u00f3l, b\u0119dzie cz\u0142onkiem klastra MariaDB-Galera, cz\u0142onkiem klastra CloudStack, serwerem KVM oraz cz\u0142onkiem klastra Ceph (dlatego mo\u017cemy zainstalowa\u0107 wszystkie pakiety od razu). Dlaczego Ceph? Dlatego \u017ce potrzebujemy wsp\u00f3\u0142dzielonej, klastrowanej przestrzeni dyskowej, bez niego nie b\u0119dzie mo\u017cliwe przenoszenie maszyn pomi\u0119dzy hostami (vMotion). Oczywi\u015bcie wspierane s\u0105 te\u017c dyski lokalne w CloudStack, niestety tutaj jeste\u015bmy zamkni\u0119ci w jednym ho\u015bcie. A my chcemy postawi\u0107 konfiguracj\u0119 zaawansowan\u0105, przypominaj\u0105c\u0105 funkcjonalnie VMware vSphere.<\/p>\n
Wr\u00f3\u0107my do storage, CloudStack potrzebuje wej\u015bciowo dw\u00f3ch przestrzeni, Primary Storage i Secondary Storage. Primary pe\u0142ni rol\u0119 g\u0142\u00f3wnej, wsp\u00f3\u0142dzielonej przestrzeni a Secondary jest udzia\u0142em NFS. W obydwu przypadkach wykorzystamy Ceph (mo\u017cna te\u017c GlusterFS je\u015bli mamy mniej ni\u017c 3 w\u0119z\u0142y), CloudStack jako jedyne znane mi rozwi\u0105zanie (typu Open Source) wspiera SharedMountPoint, jest to lokalnie zamontowana przestrze\u0144 dyskowa dost\u0119pna bezpo\u015brednio na ka\u017cdym w\u0119\u017ale z poziomu systemu plik\u00f3w. Oznacza to, \u017ce tak jak w VMware, mamy dost\u0119p fizyczny do pliko dysk\u00f3w maszyn wirtualnych (kt\u00f3re le\u017c\u0105 sobie we wsp\u00f3\u0142dzielonym katalogu). Mo\u017cna te\u017c Ceph montowa\u0107 jako udzia\u0142 RBD (blokowy) i jest to metoda preferowana dla sieci 10GB, je\u015bli konfiguracja jak\u0105 stawiamy idzie po sieci 1GB to zr\u00f3bmy to jako CephFS (osi\u0105gniemy wi\u0119ksz\u0105 wydajno\u015b\u0107 ni\u017c RBD po 1GB) ze wzgl\u0119du na mo\u017cliwo\u015b\u0107 u\u017cycia profilu cache (WriteBack) na poziomie CloudStack (zapis buforuje si\u0119 w pami\u0119ci ram). Secondary Storage wystawimy jako udzia\u0142 CephFS po NFS na ka\u017cdym w\u0119\u017ale, dost\u0119p b\u0119dzie poprzez p\u0142ywaj\u0105cy adres IP hostowany przez KeepaliveD (mo\u017cna te\u017c poprzez Ganesha NFS lub montowa\u0107 ze zdalnego serwer NFS, np. z NAS).<\/p>\n
Kontynuujemy przygotowanie w\u0119z\u0142a (na ka\u017cdym w\u0119\u017ale te ustawienia s\u0105 takie same), zaczniemy od systemu. Do poprawnego dzia\u0142ania sieci wewn\u0105trz serwer\u00f3w KVM nale\u017cy odpowiednio dostroi\u0107 parametry j\u0105dra systemu, robimy to za pomoc\u0105 zawarto\u015bci pliku \/etc\/sysctl.conf :<\/p>\n
net.ipv4.ip_forward = 1<\/span>\r\nnet.ipv4.ip_nonlocal_bind = 1<\/span>\r\nnet.ipv4.conf.default.rp_filter = 0<\/span>\r\nnet.ipv4.conf.all.rp_filter = 0\r\nnet.ipv6.conf.all.disable_ipv6 = 1\r\nnet.ipv6.conf.default.disable_ipv6 = 1\r\nfs.file-max = 100000\r\n\r\n<\/span><\/pre>\n
W przypadku SELinux i FirewallD, proponuj\u0119 wy\u0142\u0105czy\u0107 i dostroi\u0107 do w\u0142asnych potrzeb po poprawnym uruchomieniu ca\u0142o\u015bci. W kolejnym kroku konfigurujemy KVM (zmieniamy podane parametry w podanych plikach konfiguracyjnych). W\u0142\u0105czamy nas\u0142uchiwanie na porcie 16509 w ruchu nieszyfrowanym i nie autentykowanym (wymaganie podstawowe CloudStack):<\/p>\n
\/etc\/libvirtd\/libvird.conf:<\/span><\/p>\n
listen_tcp=1<\/span>\r\nlisten_tls=1<\/span>\r\ntcp_port=\u201d16509\u201d<\/span>\r\nmdns_adv=0<\/span>\r\nauth_tcp=\u201dnone\u201d<\/span><\/pre>\n
Dla CloudStack 4.11 i wy\u017cej wymagane jest po\u0142\u0105czenie szyfrowane (nawet je\u015bli wy\u0142\u0105czymy wbudowany w CloudStack CA i autentykacj\u0119 SSL). CloudStack Agent sam zmodyfikuje odpowiednio ww. plik.<\/p>\n
Nas\u0142uchiwanie konsoli VNC:<\/p>\n
\/etc\/libvirtd\/qemu.conf:<\/span>\r\nvnc_listen=0.0.0.0<\/span><\/pre>\n
Nas\u0142uchiwanie libvirtd (-l to odpowiednik \u2013listen).<\/p>\n
\/etc\/sysconfig\/libvirtd:<\/span>\r\nLIBVIRTD_ARGS=-l<\/span><\/pre>\n
Zmiany aktywujemy poprzez restart us\u0142ugi libvirtd lub hosta. W pliku konfiguracyjnym \/etc\/cloudstack\/agent\/agent.properties zmieniamy nast\u0119puj\u0105ce opcje:<\/p>\n
network.bridge.type=openvswitch<\/span>\r\nlibvirt.vif.driver=com.cloud.hypervisor.kvm.resource.OvsVifDriver<\/span><\/pre>\n
Dopisujemy linie:<\/p>\n
guest.cpu.model=SandyBridge (lub zgodne z nasz\u0105 architektur\u0105)<\/span>\r\nguest.cpu.mode=custom<\/span><\/pre>\n
Powy\u017csze ustawienia s\u0105 dobre, je\u015bli mamy hosty o r\u00f3\u017cnych procesorach (w ramach jednej architektury) i musimy uzgodni\u0107 zestaw instrukcji w ramach kt\u00f3rego b\u0119d\u0105 funkcjonowa\u0107 VM (aby umo\u017cliwi\u0107 vMotion). Sprawdzenie jakie procesory s\u0105 u nas obs\u0142ugiwane: virsh cpu-models x86_64<\/p>\n
Je\u015bli wszystkie hosty maj\u0105 t\u0119 sam\u0105 architektur\u0119 (dotyczy to fizyki ale i vm z KVM) to ustawiamy tam parametr (zapewni to najwy\u017csz\u0105 mo\u017cliw\u0105 wydajno\u015b\u0107):<\/p>\n
guest.cpu.mode=host-passthrough<\/pre>\n
Standardowe mostki sieciowe (instalowane z KVM) wchodz\u0105 w interakcj\u0119 z OpenvSwitch, nale\u017cy zablokowa\u0107 modu\u0142 j\u0105dra odpowiedzialny za ich obs\u0142ug\u0119.<\/p>\n
Tworzymy plik \/etc\/modprobe.d\/blacklist.conf z zawarto\u015bci\u0105 \u201eblacklist bridge\u201d.<\/p>\n
Przypomnijmy, na tym etapie mamy trzy (wirtualne w moim przypadku) serwery przygotowane do pe\u0142nienia wielu r\u00f3l wraz ze skonfigurowan\u0105 sieci\u0105. Budujemy \u015brodowisko odporne na awarie, HA w CloudStack oprzemy na KeepaliveD i HAProxy. CloudStack nie wspiera MariaDB-Galera wprost, dlatego b\u0119dzie si\u0119 z ni\u0105 \u0142\u0105czy\u0142 poprzez p\u0142ywaj\u0105cy adres IP kt\u00f3ry b\u0119dzie tak\u017ce punktem wej\u015bcia dla us\u0142ugi NFS, do po\u0142\u0105cze\u0144 CloudStack Agent oraz do \u0142\u0105czenia si\u0119 z interfejsem WEB CloudStack Managemen Server (oczywi\u015bcie je\u015bli stawiacie CloudStack na pojedynczej maszynie to nie potrzebujecie ani klastra Galery ani Ceph i w zasadzie mo\u017cecie pomin\u0105\u0107 dalsz\u0105 cz\u0119\u015b\u0107 posta). Dla ka\u017cdego IP tworzymy rekord DNS, w moim przypadku b\u0119dzie to:<\/p>\n
cstack.piszki.lab \u2013 192.168.70.70 (IP p\u0142ywaj\u0105cy)
\ncstack-1.piszki.lab \u2013 192.168.70.71 (w\u0119ze\u0142 1)
\ncstack-2.piszki.lab \u2013 192.168.70.72 (w\u0119ze\u0142 2)
\ncstack-3.piszki.lab \u2013 192.168.70.73 (w\u0119ze\u0142 3)<\/p>\n
Jako \u017ce ka\u017cdy w\u0119ze\u0142 jest r\u00f3wny, nie b\u0119dzie powrotu na stary serwer po jego ponownym uruchomieniu po awarii (us\u0142ugi przeskocz\u0105 i zostan\u0105 na nowym serwerze).<\/del>\u00a0Ostatecznie z tego pomys\u0142u zrezygnowa\u0142em, pierwszy w\u0119ze\u0142 jest tym r\u00f3wniejszym (head node) i na niego wr\u00f3c\u0105 wszystkie us\u0142ugi gdy wstanie. Ma to wiele zalet, np. jest te\u017c serwerem Ceph Admin, Ansible, itp itd, loguj\u0105c si\u0119 poprzez p\u0142ywaj\u0105cy IP zawsze b\u0119dziemy mieli pod r\u0119k\u0105 wszystkie narz\u0119dzia administracyjne.<\/p>\n
Konfiguracja KeepaliveD (dla KVM dzia\u0142aj\u0105cego jako wirtualna maszyna nale\u017cy zastosowa\u0107 opcje unicast), cstack-1:<\/p>\n
global_defs {\r\n   router_id CS_LAB\r\n}\r\n\r\nvrrp_script haproxy {\r\nscript \"\/usr\/bin\/killall -0 haproxy\"\r\ninterval 2\r\nweight 2\r\n}\r\n\r\nvrrp_instance CS_1 {\r\n    state MASTER\r\n    interface cloudbr0\r\n    virtual_router_id 231\r\n    priority 100\r\n    unicast_src_ip 192.168.70.71\r\n    authentication {\r\n        auth_type PASS\r\n        auth_pass 1111\r\n    }\r\n    virtual_ipaddress {\r\n        192.168.70.70\/24\r\n    }\r\n    unicast_peer {\r\n        192.168.70.72\r\n    }\r\n    track_script {\r\n    haproxy\r\n    }\r\n}<\/pre>\n
Konfiguracja dla drugiego noda, cstack-2:<\/p>\n
global_defs {\r\nrouter_id CS_LAB\r\n}\r\n\r\nvrrp_script haproxy {\r\nscript \"\/usr\/bin\/killall -0 haproxy\"\r\ninterval 2\r\nweight 2\r\n}\r\n\r\nvrrp_instance CS_1 {\r\n    state MASTER\r\n    interface cloudbr0\r\n    virtual_router_id 231\r\n    priority 50\r\n    unicast_src_ip 192.168.70.72\r\n    authentication {\r\n       auth_type PASS\r\n      auth_pass 1111\r\n    }\r\n    virtual_ipaddress {\r\n    192.168.70.70\/24\r\n    }\r\n    unicast_peer {\r\n    192.168.70.71\r\n    }\r\n    track_script {\r\n    haproxy\r\n    }\r\n}<\/pre>\n
Konfiguracja ta obs\u0142uguje us\u0142ug\u0119 MariaDB-Galera (za pomoc\u0105 skryptu clustercheck o czym b\u0119dzie ni\u017cej) oraz dost\u0119p do us\u0142ugi CloudStack Management Server (po http i https). Czas najwy\u017cszy uruchomi\u0107 sam klaster Galery, jest to bardzo proste. Tworzymy na ka\u017cdym w\u0119\u017ale w\u0142a\u015bciwy plik \/etc\/my.cnf.d\/server.conf (tutaj macie m\u00f3j, zajmie co najmniej 4GB RAM):<\/p>\n
[server]\r\n[mysqld]\r\nbind-address = 0.0.0.0\r\nbinlog_format = ROW\r\ncharacter_set_server = utf8\r\ncollation_server = utf8_general_ci\r\ndatadir = \/var\/lib\/mysql\r\ndefault_storage_engine = InnoDB\r\nexpire_logs_days = 10\r\ninnodb_autoinc_lock_mode = 2\r\ninnodb_buffer_pool_size = 512M\r\ninnodb_log_file_size = 1024M\r\ninnodb_doublewrite = 1\r\ninnodb_file_per_table = 1\r\ninnodb_flush_log_at_trx_commit = 2\r\ninnodb_lock_wait_timeout = 600\r\ninnodb_stats_on_metadata = 0\r\nkey_buffer_size = 128M\r\nlock_wait_timeout = 300\r\nmax_allowed_packet = 1G\r\nmax_statement_time = 100\r\nmax_binlog_size = 64M\r\nmax_connections = 500\r\nmyisam_sort_buffer_size = 32M\r\nnet_buffer_length = 8K\r\nquery_cache_limit = 32M\r\nquery_cache_size = 64M\r\nread_buffer_size = 4M\r\nread_rnd_buffer_size = 4M\r\nskip-external-locking\r\nsort_buffer_size = 8M\r\ntable_cache = 2048\r\ntable_definition_cache = 32345\r\ntable_open_cache = 32345\r\nthread_cache_size = 100\r\nlog_error = \/var\/log\/mariadb\/mariadb_error.log\r\nlog_warnings = 1\r\n#general_log_file = \/var\/log\/mariadb\/mariadb.log\r\n#general_log = 1\r\n\r\n[galera]\r\nwsrep_on=ON\r\nwsrep_provider=\/usr\/lib64\/galera\/libgalera_smm.so\r\nwsrep_cluster_address=\"gcomm:\/\/192.168.70.71,192.168.70.72,192.168.70.73\"\r\nwsrep_cluster_name=\"cloudstack_db\"\r\nwsrep_node_name=\"H1\"\r\nwsrep_node_address=\"192.168.70.71\"\r\n#wsrep_sst_method=rsync\r\n#wsrep_sst_auth=sst_user:dbpass<\/pre>\n
[embedded]<\/span>\r\n[mariadb]<\/span>\r\n[mariadb-10.1]<\/span>\r\n[mysqldump]<\/span>\r\nmax_allowed_packet = 16M<\/span>\r\nquick<\/span>\r\nquote-names<\/span>\r\n[mysql]<\/span>\r\n[isamchk]<\/span>\r\nkey_buffer = 256M<\/span>\r\nread_buffer = 16M<\/span>\r\nsort_buffer_size = 256M<\/span>\r\nwrite_buffer = 16M<\/span><\/pre>\n
Na ka\u017cdym w\u0119\u017ale poprawiamy node_name i node_address i uruchamiamy na pierwszym w\u0119\u017ale poleceniem galera_new_cluster (wystartowanie nowego klastra jest potrzebne zawsze gdy wy\u0142\u0105czone b\u0119d\u0105 wszystkie w\u0119z\u0142y). Na pozosta\u0142ych startujemy standardowo systemctl start\/enable mariadb i dalej mysql_secure_installation (w tym przyk\u0142adzie has\u0142o na root db ustawiamy na dbpass).<\/p>\n
Teraz skonfigurujemy skrypt clustercheck:<\/p>\n
wget https:\/\/raw.githubusercontent.com\/olafz\/percona-clustercheck\/master\/clustercheck<\/span><\/p>\n
chmod +x clustercheck
\nmv clustercheck \/usr\/bin\/<\/span><\/p>\n
vi \/etc\/xinetd.d\/mysqlchk<\/span><\/p>\n
# default: on\r\n# description: mysqlchk\r\nservice mysqlchk\r\n{\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 disable = no\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 flags = REUSE\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 socket_type = stream\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 port = 9200\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 # This port used by xinetd for clustercheck\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 wait = no\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 user = nobody\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 server = \/usr\/bin\/clustercheck\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 log_on_failure += USERID\r\n        log_on_success =\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 only_from = 0.0.0.0\/0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 per_source = UNLIMITED\r\n}<\/span><\/pre>\n
vi \/etc\/services<\/span><\/p>\n
mysqlchk\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 9200\/tcp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 # mysqlchk\r\n#wap-wsp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 9200\/tcp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 # WAP connectionless session service\r\n#wap-wsp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 9200\/udp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 # WAP connectionless session service<\/span><\/pre>\n
systemctl start\/enable xinetd<\/span><\/p>\n
mysql -u root -p
\nGRANT PROCESS ON *.* TO 'clustercheckuser’@’localhost’ IDENTIFIED BY 'clustercheckpassword!’ ;
\nexit;<\/span><\/p>\n
Testy (je\u015bli macie b\u0142\u0105d, to sprawd\u017acie w skrypcie clustercheck czy prawid\u0142owo podany jest u\u017cytkownik i has\u0142o):<\/p>\n
[root@cstack-2 ~]# \/usr\/bin\/clustercheck\r\nHTTP\/1.1 200 OK\r\nContent-Type: text\/plain\r\nConnection: close\r\nContent-Length: 40<\/span>\r\n\r\nPercona XtraDB Cluster Node is synced.<\/span><\/pre>\n
W kolejnym kroku konfigurujemy HAProxy:<\/p>\n
global\r\nlog         127.0.0.1 local2\r\n\r\nchroot      \/var\/lib\/haproxy\r\npidfile     \/var\/run\/haproxy.pid\r\nmaxconn     4000\r\nuser        haproxy\r\ngroup       haproxy\r\ndaemon\r\n\r\nstats socket \/var\/lib\/haproxy\/stats\r\n\r\ndefaults\r\nmode                    http\r\nlog                     global\r\noption                  tcplog\r\noption                  dontlognull\r\noption http-server-close\r\noption                  redispatch\r\nretries                 3\r\ntimeout http-request    10s\r\ntimeout queue           1m\r\ntimeout connect         10s\r\ntimeout client          1m\r\ntimeout server          1m\r\ntimeout http-keep-alive 10s\r\ntimeout check           10s\r\nmaxconn                 3000\r\n\r\nlisten mariadb_cluster 0.0.0.0:3030\r\nmode tcp\r\nbalance leastconn\r\nserver cstack-1:3306 192.168.70.71:3306 check port 9200\r\nserver cstack-2:3306 192.168.70.72:3306 check port 9200 backup\r\nserver cstack-3:3306 192.168.70.73:3306 check port 9200 backup\r\n\r\nlisten stats 0.0.0.0:9000\r\nmode http\r\nstats enable\r\nstats uri \/stats\r\nstats realm HAProxy\\ Statistics\r\nstats auth admin:admin\r\nstats admin if TRUE\r\n\r\nfrontend ui\r\n        bind 192.168.70.70:80\r\n        mode http\r\n        option forwardfor\r\n        option httplog\r\n        use_backend uib\r\n\r\nfrontend uis\r\n        bind 192.168.70.70:443 ssl crt \/etc\/haproxy\/cloud.pem\r\n        mode http\r\n        option httpclose\r\n        option forwardfor\r\n        reqadd X-Forwarded-Proto:\\ https\r\n        use_backend uib\r\n\r\nbackend uib\r\n        option httpchk OPTIONS \/client\r\n        balance source\r\n        server cstack-1:8080 192.168.70.71:8080 maxconn 32 check\r\n        server cstack-2:8080 192.168.70.72:8080 maxconn 32 check backup<\/pre>\n
Testy:<\/pre>\n
mysql -u root -p
\nGRANT ALL PRIVILEGES ON *.* TO root@’%’ IDENTIFIED BY „dbpass”;<\/span><\/p>\n
mysql -u root -p -h 192.168.70.X -P 3030 -e „select Host, User, Password from mysql.user”<\/span><\/p>\n
W\u0142\u0105czenie logowania HAProxy (dla rsyslogd), plik \/etc\/rsyslog.d\/haproxy.conf:<\/p>\n
local2.* \/var\/log\/haproxy.log
\nlocal2.=info \/var\/log\/haproxy-info.log
\nlocal2.notice \/var\/log\/haproxy-allbutinfo.log<\/p>\n
Dzi\u0119ki takiej konfiguracji uzyskali\u015bmy klaster MariaDB-Galera dost\u0119pny na porcie 3030 poprzez ka\u017cdy adres IP (w tym najwa\u017cniejszy, p\u0142ywaj\u0105cy), ka\u017cde po\u0142\u0105czenie jest balansowane przez HAProxy pomi\u0119dzy wszystkimi w\u0119z\u0142ami. Taka konfiguracja zabezpieczy CloudStack Management Server przed awariami w\u0119z\u0142\u00f3w. Dodatkowo mamy podgl\u0105d na prac\u0119 HAProxy pod adresem http:\/\/192.168.70.70:9000\/stats. Na t\u0119 chwil\u0119 zostawimy Galer\u0119 i przejdziemy do Ceph. Instalacja i uruchomienie Ceph<\/a> jest bardzo proste, musimy jedynie spe\u0142ni\u0107 podstawy warunek, minimum trzy serwery i minimum jeden dysk per serwer przeznaczony pod pul\u0119 dyskow\u0105. Mo\u017cna zmusi\u0107 Ceph do uruchomienia na jednym i dw\u00f3ch w\u0119z\u0142ach ale to ju\u017c jest d\u0142ubanie i pozostawiam to Wam (mo\u017cecie te\u017c zastosowa\u0107 GlusterFS 1:1).<\/p>\n
Na wybranym w\u0119\u017ale kt\u00f3ry b\u0119dzie pe\u0142ni\u0142 rol\u0119 Admin Server dla Ceph instalujemy pakiet ceph-deploy (a na ka\u017cdym ceph-fuse). Dodatkowo dla u\u017cytkownika kt\u00f3ry b\u0119dzie pe\u0142ni\u0142 rol\u0119 Admin Ceph (np. root) generujemy klucz ssh (ssh-keygen z pustym has\u0142em) i rozsy\u0142amy go poleceniem ssh-copy-id na pozosta\u0142e w\u0119z\u0142y. Rezultat jaki musimy osi\u0105gn\u0105\u0107 to mo\u017cliwo\u015b\u0107 zalogowania si\u0119 po ssh bez has\u0142a na ka\u017cdy w\u0119ze\u0142. Tworzymy te\u017c plik (uprawnienia 644):<\/p>\n
[root@cstack-1 .ssh]# cat config<\/p>\n
Host cstack-1\r\nHostname cstack-1\r\nUser root\r\nHost cstack-2\r\nHostname cstack-2\r\nUser root\r\nHost cstack-3\r\nHostname cstack-3\r\nUser root<\/pre>\n
Nast\u0119pnie wydajemy polecenie (najlepiej w jakim\u015b katalogu a nie w katalogu domowym u\u017cytkownika):<\/p>\n
ceph-deploy new cstack-1 cstack-2 cstack-3<\/p>\n
W ten spos\u00f3b uzyskamy inicjaln\u0105 konfiguracj\u0119 Ceph, modyfikujemy plik ceph.conf do postaci jaka nas interesuje (tutaj m\u00f3j):<\/p>\n
[root@cstack-1 ceph]# cat ceph.conf<\/span><\/p>\n
[global]\r\nfsid = 9d9d1a99-c5f0-4b93-acca-37245488002d\r\nmon_initial_members = cstack-1, cstack-2, cstack-3\r\nmon_host = 192.168.70.71,192.168.70.72,192.168.70.73\r\nauth_cluster_required = cephx\r\nauth_service_required = cephx\r\nauth_client_required = cephx\r\nosd_pool_default_size = 2\r\nosd_pool_default_min_size = 2\r\nosd pool default pgp num = 256\r\nosd pool default pg num = 256\r\nosd max object name len = 256\r\nosd max object namespace len = 64\r\nmon_allow_pool_delete = True\r\n#public network = 192.168.70.0\/24\r\n#cluster network = 172.18.37.0\/24\r\n\r\n[osd]\r\nosd mkfs options xfs = -f -i size=2048\r\nosd mkfs type = xfs\r\nosd journal size = 5120\r\nosd mount options xfs = noatime,largeio,inode64,swalloc<\/pre>\n
Zmienne public network i cluster network definiuj\u0105 nam sieci kt\u00f3rymi Ceph udost\u0119pnia i wymienia pomi\u0119dzy w\u0119z\u0142ami dane. Nie s\u0105 obligatoryjne, je\u015bli ich nie u\u017cyjemy to ca\u0142a komunikacja p\u00f3jdzie g\u0142\u00f3wnym interfejsem sieciowym maszyny (zalecane jest jednak aby sz\u0142o to osobnymi interfejsami). Nast\u0119pnie wykonujemy polecenie:<\/p>\n
ceph-deploy install cstack-1 cstack-2 cstack-3<\/span><\/p>\n
<\/pre>\n
(mo\u017cna j\u0105 ponawia\u0107 np. dla wybranego serwera gdy co\u015b b\u0119dzie nie tak). Je\u015bli instalacja wykona\u0142a si\u0119 poprawnie, wykonujemy polecenie:<\/p>\n
ceph-deploy mon create-initial<\/span><\/p>\n
<\/pre>\n
(roze\u015blemy konfiguracj\u0119 do w\u0119z\u0142\u00f3w). Teraz wydajemy polecenie:<\/p>\n
ceph-deploy gatherkeys cstack-1<\/span><\/p>\n
ceph-deploy admin cstack-1 cstack-2 cstack-3<\/span><\/p>\n
<\/pre>\n
(roze\u015blemy klucz administracyjny umo\u017cliwiaj\u0105cy dzia\u0142anie polecenia ceph, np. ceph \u2013w do monitorowania stanu klastra) i na ko\u0144cu:<\/p>\n
ceph-deploy mgr create cstack-1 cstack-2 cstack-3<\/span><\/p>\n
<\/pre>\n
Na tym etapie mamy dzia\u0142aj\u0105cy klaster Ceph bez pod\u0142\u0105czonych dysk\u00f3w (OSD). Przygotowanie i aktywowanie dysk\u00f3w jest r\u00f3wnie proste, u mnie pod OSD id\u0105 dyski sdb, wykonujemy polecenie (dla Ceph Luminous i nowszych z fs bluestore):<\/p>\n
ceph-deploy osd prepare –bluestore –block-db \/dev\/sdb –block-wal \/dev\/sdb cstack-2:sdb<\/p>\n
ceph-deploy osd activate cstack-2:sdb1<\/p>\n
Dla wersji Mimic i nowszych: ceph-deploy osd create --data \/dev\/sdb cstack-2 (dla ka\u017cdego hosta, per dysk)<\/pre>\n
Testy:<\/p>\n
[root@cstack-1 ceph]# ceph osd tree\r\nID CLASS WEIGHT\u00a0 TYPE NAME\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 STATUS REWEIGHT PRI-AFF\r\n-1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.29095 root default\r\n-3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.09698\u00a0\u00a0\u00a0\u00a0 host cstack-1\r\n0\u00a0\u00a0 hdd 0.09698\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 osd.0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 up\u00a0 1.00000 1.00000\r\n-5\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.09698\u00a0\u00a0\u00a0\u00a0 host cstack-2\r\n1\u00a0\u00a0 hdd 0.09698\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 osd.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 up\u00a0 1.00000 1.00000\r\n-7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0.09698\u00a0\u00a0\u00a0\u00a0 host cstack-3\r\n2\u00a0\u00a0 hdd 0.09698\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 osd.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 up\u00a0 1.00000 1.00000\r\n[root@cstack-1 ceph]# ceph -s\r\ncluster:\r\nid:\u00a0\u00a0\u00a0\u00a0 b1bf8ac2-d9b6-486c-9ca5-6abd59e6d20e\r\nhealth: HEALTH_OK\r\n\r\nservices:\r\nmon: 3 daemons, quorum cstack-1,cstack-2,cstack-3\r\nmgr: cstack-1(active), standbys: cstack-3, cstack-2\r\nosd: 3 osds: 3 up, 3 in\r\n\r\ndata:\r\npools:\u00a0\u00a0 0 pools, 0 pgs\r\nobjects: 0 objects, 0 bytes\r\nusage:\u00a0\u00a0 6149 MB used, 292 GB \/ 298 GB avail\r\npgs:<\/pre>\n
Czyli mamy dzia\u0142aj\u0105cy klaster Ceph, trzy w\u0119z\u0142y, trzy dyski, trzy monitory. To nie koniec, dla CephFS musimy jeszcze uruchomi\u0107 MetaDadata Server, stworzy\u0107 FS i zamontowa\u0107 go lokalnie na ka\u017cdym serwerze. Je\u015bli wielko\u015b\u0107 128 jest zbyt du\u017ca dla Was (komunikat o b\u0142\u0119dzie) to dopasujcie j\u0105 do wielko\u015bci dysku zmniejszaj\u0105c odpowiednio podane warto\u015bci.<\/p>\n
ceph-deploy mds create cstack-1 cstack-2 cstack-3<\/span><\/p>\n
ceph osd pool create cephfs_data 128 <\/span><\/p>\n
ceph osd pool create cephfs_metadata 128<\/span><\/p>\n
ceph fs new cephfs cephfs_metadata cephfs_data<\/span><\/p>\n
Testy:<\/p>\n
[root@cstack-1 ceph]# ceph mds stat
\ncephfs-1\/1\/1 up\u00a0 {0=cstack-3=up:active}, 2 up:standby<\/p>\n
Teraz pozostaje zamontowa\u0107 wolumen cephfs lokalnie na ka\u017cdym w\u0119\u017ale, 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\u017cy pozostawi\u0107 jedynie warto\u015b\u0107 klucza):<\/p>\n
192.168.70.71:6789:\/\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/data\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ceph\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 name=admin,secretfile=\/etc\/ceph.key,_netdev,noatime\u00a0\u00a0\u00a0\u00a0 0 2<\/p>\n
W CentOS 7 (w innych systemach te\u017c) mo\u017cemy montowa\u0107 udzia\u0142 w formie us\u0142ugi SystemD, jest to metoda preferowana o ile mamy us\u0142ugi zale\u017cne od zamontowania udzia\u0142u. A tak\u0105 jest np. CloudStack Agent, dzi\u0119ki temu wszystko mo\u017cna poustawia\u0107 w odpowiedniej kolejno\u015bci aby w trakcie systemu nie by\u0142o problem\u00f3w.<\/p>\n
Na ko\u0144cu b\u0119dziemy potrzebowali udzia\u0142u NFS, udzia\u0142 ten b\u0119dzie wykorzystywany przez maszyn\u0119 systemow\u0105 CloudStack Secondary Storage VM i s\u0142u\u017cy do przechowywania template maszyn systemowych (routery wirtualne), template maszyn kt\u00f3re zrobicie i snapshot\u00f3w. Mo\u017cna u\u017cy\u0107 dowolnego serwera NFS (np. NAS), ja uruchomi\u0119 lokalnie na ka\u017cdym w\u0119\u017ale serwer NFS dla katalogu \/data\/nfs a montowa\u0107 udzia\u0142 b\u0119d\u0119 poprzez p\u0142ywaj\u0105cy adres IP. Dzi\u0119ki temu awaria jednego z w\u0119z\u0142\u00f3w nie spowoduje niedost\u0119pno\u015bci serwera NFS (tak\u0105 sam\u0105 funkcjonalno\u015b\u0107 daje Ganesha NFS). Uruchamiamy potrzebne us\u0142ugi:<\/p>\n
systemctl enable rpcbind\r\nsystemctl enable nfs-server\r\nsystemctl enable nfs-lock\r\nsystemctl enable nfs-idmap\r\nsystemctl start rpcbind\r\nsystemctl start nfs-server\r\nsystemctl start nfs-lock\r\nsystemctl start nfs-idmap<\/span><\/pre>\n
I robimy wpis w pliku \/etc\/exports:<\/p>\n
\/data\/nfs\u00a0 \u00a0 \u00a0 \u00a0192.168.70.0\/24(rw,sync,no_root_squash,no_all_squash)<\/span><\/p>\n
Na koniec uwagi o optymalizacji. Nigdzie wcze\u015bniej nie pisa\u0142em o DNS i NTP, ale to oczywista oczywisto\u015b\u0107, zsynchronizowane czasowo nody to dla MariaDB Galera i Ceph co\u015b bez czego us\u0142ugi si\u0119 roz\u0142o\u017c\u0105. W CentOS 7 mamy domy\u015blnie zainstalowan\u0105 i uruchomion\u0105 us\u0142ug\u0119 dynamicznego tuningu KSM. Warto sprawdzi\u0107 (tuned-adm active) jaki mamy profil aktywny i dla hosta zmieni\u0107 go na virtual-host (nawet je\u015bli jest to zagnie\u017cd\u017cony, wirtualny KVM). Warto wy\u0142\u0105czy\u0107 splash screen w trakcie boottowania systemu (usuwamy rhgb quiet) oraz w\u0142\u0105czy\u0107 obs\u0142ug\u0119 IOMMU (nawet w wirtualnym KVM), robimy to w \/etc\/default\/grub:<\/p>\n
GRUB_CMDLINE_LINUX=\"crashkernel=auto rd.lvm.lv=VolumeGroup\/lvm_root nouveau.modeset=0 rd.driver.blacklist=nouveau plymouth.ignore-udev intel_iommu=on\"<\/pre>\n
Warto sprawdzi\u0107 czy spe\u0142niamy wszystkie warunki dla poprawnej i wydajnej pracy KVM poleceniem: virt-host-validate<\/p>\n
I to w tym po\u015bcie na tyle. Du\u017co pracy trzeba wykona\u0107 ale jest ona niezb\u0119dna aby p\u00f3\u017aniej na poziomie CloudStack unikn\u0105\u0107 problem\u00f3w. Dobrze przygotowany w\u0119ze\u0142 to podstawa. W kolejnym po\u015bcie uruchomimy CloudStack i wykonamy inicjaln\u0105 konfiguracj\u0119. Mam nadziej\u0119 \u017ce jeszcze si\u0119 nie zniech\u0119cili\u015bcie, tak na prawd\u0119, przy odrobinie wprawy ca\u0142o\u015b\u0107 instalacji i konfiguracji sporego \u015brodowiska zajmuje dzie\u0144 maksymalnie dwa. Jak do tego do\u0142o\u017cymy Ansible to postawienie CloudStack zajmuje chwil\u0119.<\/p>\n
<\/div>","protected":false},"excerpt":{"rendered":"
W poprzednich cz\u0119\u015bciach zapoznali\u015bmy si\u0119 z terminologi\u0105 CloudStack i z konfiguracj\u0105 sieci na w\u0119z\u0142ach. W tym po\u015bcie skupimy si\u0119 na przygotowaniu w\u0119z\u0142\u00f3w do pe\u0142nienia roli serwera wirtualizacji oraz poczynimy pierwsze kroki w konfiguracji \u015brodowiska zarz\u0105dczego. Niestety, w mi\u0119dzy czasie musia\u0142em … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":3343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"yasr_overall_rating":0,"yasr_post_is_review":"","yasr_auto_insert_disabled":"","yasr_review_type":"","footnotes":""},"categories":[45],"tags":[116,108,117],"class_list":["post-3446","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-poradniki","tag-cloudstack","tag-kvm","tag-openvswitch"],"yasr_visitor_votes":{"stars_attributes":{"read_only":false,"span_bottom":false},"number_of_votes":1,"sum_votes":5},"_links":{"self":[{"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/posts\/3446"}],"collection":[{"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3446"}],"version-history":[{"count":17,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/posts\/3446\/revisions"}],"predecessor-version":[{"id":3548,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/posts\/3446\/revisions\/3548"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=\/wp\/v2\/media\/3343"}],"wp:attachment":[{"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vm.piszki.pl\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}