L'Imp'Rock Scénette (by @_daffyduke_)

Notes Meetup Docker - chez GFI

Olivier Duquesne aka DaffyDuke — 2017-02-23T18:29:00Z

VSCT

2015 openstack en réaction à aws
2016 docker + MEP openstack
mutation socité é DEVOPS
création d'une plateforme VSCloud, build fast & chip
Environ 10 applis en prod docker (essentiellement applis internes) ou le site
de recrutement
openstack par hp (helion)
(avec un debut brique à brique pour expérimenter )
git puppet consul jenkins consul-hproxy swarm register jira

tenant + swarm + catalogue d'image docker tomcat, mysql, ....
avec consul / nginx / ...
jenkins en mode pipeline pour le dploiement des conteneurs

puis l'equipe de prod deploie en prod
dans le même tenant (2 swarm + 1 VM bastion)

c'est jenkins qui ordonnance les install' avec u go humain pour la prod

puppet crée le tenant pour donner à manger à heat
(avant rundeck + heat)
fail fast sur consul (pas encore de bdd à rollbacker)
flocker pour le backup de base en cron
sur des SLA nuls :-)

vision à 2 ans pour la scalabilité

planif de MEP encore

garantie de la prod : prod ou dev ? c'est le dev qui a la main sur le contenu
pas la prod "comme avant"
besoin de changement d'organisation

autre solution kafka-manager

recrutement vsct com

openstack = 1 IP entrante

supervision cetreon mais pas simple sur docker ....

ADEO

rancher
pas de maturite en prod, c'est le dev qui pousse

Notes Susecon 2016 - Washington

Olivier Duquesne aka DaffyDuke — 2016-11-07T17:53:00Z

CEPH, OpenSorce, Software Defined Storage, LTS de 12 mois, Suse Storage 3 basee sur Jewel release jusqu qu 6 milliards de noeuds par cluster CERN et toutes les distrib ou constructeurs sont membres du management CEPH usual strategy is to scale up (vertical) ceph is for scaling out (horizontal) suse is the first to ship a iscsi gateway wih ceph (supported) RADOS = CEPH cluster, stockage objet Librados = app pour acceder aux donnees (C, PHP, Java etc) Radosgw = gateway REST co;\mpatible S3, Swift RBD = block sur host qui heberge une instance CEPH FS = fs pour un client la gatway irbd presente les donnees en iscsi ou nfs etc 2 co;posants i;portants : - un OSD pour manager les disques (one per path) - MONS (3, $, ....), pour monitorer le cluster Un algo CRUSH de stockage Disk-> FileSystem (XFS) -> OSD Les donnes sont stockees via algo CRUSH Mimu;m de 3 MONS, utilise algo PAXOS pour monitorer les nodes et le reseau => i;pair absoluement monitor map, contient placement group map, CRUSH map, epoch pour garantir integrite des donnes rssayer de mettre le moins possible de mons un client accede a la donnee objet en ;ode osd directement PAXOS election de l ip la plus petite pour elire un MON les objets sont ranges dans des storage pools defaultpool rbd regles de placement de snapshot par pool l osd voit les placement group, chaque objet est associe a um placement group il faut faire attention au nbre de PG CRUSH controllable Replication Under les donnes ne sont pas centralisees OSD run CRUSH => besoin de CPU Step2, install, hardware voir la doc suse ceph unprivileged, 167 if possible DNS recommande ipv4 tres bien timesync and at least 2 networks : pub for client/admin and priv for osd to osd SES3 dispo en extension de SLES 12sp0 zypper in ceph-deploy and that s all folks ceph-deploy install <node list> ceph-deply new -cluster moncluster <node list> ceph.conf contient les cles et le rep du journal ceph-deploy mon create-initial <node list> utiliser create pour ajouter des nodes MON puis ajouter les OSD ceph-deploy osd prepare node:dev when check with ceph -k ceph.client.admin.keyring status ceph -w (watch) geeko@ses-admin:~/Desktop> sudo su - We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. root's password: ses-admin:~ # yast yast yast2 ses-admin:~ # yast2 ses-admin:~ # useradd -m cephadm ses-admin:~ # passwd cephadm New password: BAD PASSWORD: it is too short BAD PASSWORD: is too simple Retype new password: passwd: password updated successfully ses-admin:~ # visudo visudo: /etc/sudoers.tmp unchanged ses-admin:~ # visudo ses-admin:~ # su – cephadm su: user – does not exist ses-admin:~ # su - cephadm cephadm@ses-admin:~> ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/cephadm/.ssh/id_rsa): Created directory '/home/cephadm/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/cephadm/.ssh/id_rsa. Your public key has been saved in /home/cephadm/.ssh/id_rsa.pub. The key fingerprint is: 9e:b2:bd:31:6f:32:10:b6:7e:84:77:33:79:86:a3:e6 [MD5] cephadm@ses-admin The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | o | | . +S o | | +.o.B o | | ..+=o * | | .+*+. | | .+E=. | +--[MD5]----------+ cephadm@ses-admin:~> ssh-copy-id cephadm@ses-node1 The authenticity of host 'ses-node1 (192.168.100.11)' can't be established. ECDSA key fingerprint is 33:4d:5a:db:e7:69:26:2b:90:11:91:ad:ab:3d:49:eb [MD5]. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'cephadm@ses-node1'" and check to make sure that only the key(s) you wanted were added. cephadm@ses-admin:~> ssh-copy-id cephadm@ses-node2 The authenticity of host 'ses-node2 (192.168.100.12)' can't be established. ECDSA key fingerprint is 33:4d:5a:db:e7:69:26:2b:90:11:91:ad:ab:3d:49:eb [MD5]. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'cephadm@ses-node2'" and check to make sure that only the key(s) you wanted were added. cephadm@ses-admin:~> ssh-copy-id cephadm@ses-node3 The authenticity of host 'ses-node3 (192.168.100.13)' can't be established. ECDSA key fingerprint is 33:4d:5a:db:e7:69:26:2b:90:11:91:ad:ab:3d:49:eb [MD5]. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'cephadm@ses-node3'" and check to make sure that only the key(s) you wanted were added. cephadm@ses-admin:~> ssh ses-node3 id uid=1001(cephadm) gid=100(users) groups=100(users) cephadm@ses-admin:~> exit logout ses-admin:~ # zypper in ceph ceph-deploy Loading repository data... Reading installed packages... Resolving package dependencies... The following 42 NEW packages are going to be installed: FastCGI babeltrace ceph ceph-base ceph-common ceph-deploy ceph-mds ceph-mon ceph-osd gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-Flask python-Jinja2 python-MarkupSafe python-Werkzeug python-apipkg python-argparse python-cephfs python-ecdsa python-execnet python-itsdangerous python-paramiko python-pushy python-pycrypto python-rados python-rbd python-remoto python-requests supportutils-plugin-ses The following package is not supported by its vendor: libxio 42 new packages to install. Overall download size: 48.7 MiB. Already cached: 0 B. After the operation, additional 211.7 MiB will be used. Continue? [y/n/? shows all options] (y): y Retrieving package python-Werkzeug-0.9.6-5.2.noarch (1/42), 483.9 KiB ( 2.2 MiB unpacked) Retrieving package python-apipkg-1.2-1.2.noarch (2/42), 9.2 KiB ( 18.2 KiB unpacked) Retrieving package python-ecdsa-0.13-2.1.noarch (3/42), 77.4 KiB (261.8 KiB unpacked) Retrieving package python-itsdangerous-0.24-2.1.noarch (4/42), 20.2 KiB ( 69.1 KiB unpacked) Retrieving package supportutils-plugin-ses-1.0+git.1463485157.269428c-4.1.noarch (5/42), 13.7 KiB ( 26.0 KiB unpacked) Retrieving package FastCGI-2.4.0-167.1.x86_64 (6/42), 184.8 KiB (587.6 KiB unpacked) Retrieving package libboost_random1_54_0-1.54.0-13.1.x86_64 (7/42), 20.0 KiB ( 10.3 KiB unpacked) Retrieving package libleveldb1-1.18-1.3.x86_64 (8/42), 132.8 KiB (361.3 KiB unpacked) Retrieving package python-MarkupSafe-0.18-7.1.x86_64 (9/42), 24.6 KiB ( 66.0 KiB unpacked) Retrieving package python-pycrypto-2.6.1-4.1.x86_64 (10/42), 371.5 KiB ( 2.0 MiB unpacked) Retrieving package python-execnet-1.4.1-1.3.noarch (11/42), 73.7 KiB (249.5 KiB unpacked) Retrieving package python-Jinja2-2.7.3-17.1.noarch (12/42), 278.5 KiB ( 1.7 MiB unpacked) Retrieving package python-paramiko-1.15.2-1.1.noarch (13/42), 860.0 KiB ( 5.1 MiB unpacked) Retrieving package python-remoto-0.0.27-1.1.noarch (14/42), 80.6 KiB (298.2 KiB unpacked) Retrieving package python-Flask-0.10.1-2.1.noarch (15/42), 178.0 KiB (827.7 KiB unpacked) Retrieving package python-pushy-0.5.3-1.5.noarch (16/42), 58.3 KiB (238.5 KiB unpacked) Retrieving package python-argparse-1.2.1-15.8.noarch (17/42), 248.6 KiB (490.1 KiB unpacked) Retrieving package python-requests-2.3.0-6.5.2.noarch (18/42), 334.6 KiB ( 1.7 MiB unpacked) Retrieving package babeltrace-1.2.4-3.2.x86_64 (19/42), 159.0 KiB (463.9 KiB unpacked) Retrieving package gperftools-2.2-2.2.x86_64 (20/42), 554.3 KiB ( 2.2 MiB unpacked) Retrieving package libboost_iostreams1_54_0-1.54.0-13.1.x86_64 (21/42), 39.8 KiB (103.1 KiB unpacked) Retrieving package libboost_program_options1_54_0-1.54.0-13.1.x86_64 (22/42), 125.5 KiB (456.7 KiB unpacked) Retrieving package libibverbs1-1.1.7-12.2.x86_64 (23/42), 34.1 KiB ( 71.4 KiB unpacked) Retrieving package liburcu0-0.8.8-1.2.x86_64 (24/42), 49.4 KiB (182.6 KiB unpacked) Retrieving package librdmacm1-1.0.18.1-1.14.x86_64 (25/42), 53.4 KiB (129.1 KiB unpacked) Retrieving package lttng-ust-2.7.0-1.2.x86_64 (26/42), 171.4 KiB (754.7 KiB unpacked) Retrieving package ceph-deploy-1.5.32+git.1464082518.5aab689-1.1.noarch (27/42), 174.7 KiB (740.3 KiB unpacked) Retrieving package libxio-1.6+git.1461071064.e0ed264-2.1.x86_64 (28/42), 242.5 KiB (885.9 KiB unpacked) Retrieving package librados2-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (29/42), 1.7 MiB ( 6.3 MiB unpacked) Retrieving package libcephfs1-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (30/42), 1.8 MiB ( 6.0 MiB unpacked) Retrieving package python-rados-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (31/42), 209.0 KiB (493.4 KiB unpacked) Retrieving package librgw2-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (32/42), 2.7 MiB ( 10.3 MiB unpacked) Retrieving package librbd1-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (33/42), 2.1 MiB ( 7.5 MiB unpacked) Retrieving package libradosstriper1-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (34/42), 1.8 MiB ( 6.9 MiB unpacked) Retrieving package python-cephfs-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (35/42), 138.1 KiB (227.4 KiB unpacked) Retrieving package python-rbd-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (36/42), 133.1 KiB (184.9 KiB unpacked) Retrieving package ceph-common-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (37/42), 14.9 MiB ( 67.1 MiB unpacked) Retrieving package ceph-base-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (38/42), 3.9 MiB ( 33.1 MiB unpacked) Retrieving package ceph-osd-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (39/42), 9.0 MiB ( 33.2 MiB unpacked) Retrieving package ceph-mon-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (40/42), 2.7 MiB ( 9.3 MiB unpacked) Retrieving package ceph-mds-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (41/42), 2.7 MiB ( 9.3 MiB unpacked) Retrieving package ceph-10.2.1+git.1464009581.b8ee9e4-1.1.x86_64 (42/42), 79.1 KiB ( 0 B unpacked) Checking for file conflicts: .............................................................................[done] ( 1/42) Installing: python-Werkzeug-0.9.6-5.2 ............................................................[done] ( 2/42) Installing: python-apipkg-1.2-1.2 ................................................................[done] ( 3/42) Installing: python-ecdsa-0.13-2.1 ................................................................[done] ( 4/42) Installing: python-itsdangerous-0.24-2.1 .........................................................[done] ( 5/42) Installing: supportutils-plugin-ses-1.0+git.1463485157.269428c-4.1 ...............................[done] ( 6/42) Installing: FastCGI-2.4.0-167.1 ..................................................................[done] ( 7/42) Installing: libboost_random1_54_0-1.54.0-13.1 ....................................................[done] ( 8/42) Installing: libleveldb1-1.18-1.3 .................................................................[done] ( 9/42) Installing: python-MarkupSafe-0.18-7.1 ...........................................................[done] (10/42) Installing: python-pycrypto-2.6.1-4.1 ............................................................[done] (11/42) Installing: python-execnet-1.4.1-1.3 .............................................................[done] (12/42) Installing: python-Jinja2-2.7.3-17.1 .............................................................[done] (13/42) Installing: python-paramiko-1.15.2-1.1 ...........................................................[done] (14/42) Installing: python-remoto-0.0.27-1.1 .............................................................[done] (15/42) Installing: python-Flask-0.10.1-2.1 ..............................................................[done] (16/42) Installing: python-pushy-0.5.3-1.5 ...............................................................[done] (17/42) Installing: python-argparse-1.2.1-15.8 ...........................................................[done] (18/42) Installing: python-requests-2.3.0-6.5.2 ..........................................................[done] (19/42) Installing: babeltrace-1.2.4-3.2 .................................................................[done] (20/42) Installing: gperftools-2.2-2.2 ...................................................................[done] (21/42) Installing: libboost_iostreams1_54_0-1.54.0-13.1 .................................................[done] (22/42) Installing: libboost_program_options1_54_0-1.54.0-13.1 ...........................................[done] (23/42) Installing: libibverbs1-1.1.7-12.2 ...............................................................[done] (24/42) Installing: liburcu0-0.8.8-1.2 ...................................................................[done] (25/42) Installing: librdmacm1-1.0.18.1-1.14 .............................................................[done] (26/42) Installing: lttng-ust-2.7.0-1.2 ..................................................................[done] (27/42) Installing: ceph-deploy-1.5.32+git.1464082518.5aab689-1.1 ........................................[done] (28/42) Installing: libxio-1.6+git.1461071064.e0ed264-2.1 ................................................[done] (29/42) Installing: librados2-10.2.1+git.1464009581.b8ee9e4-1.1 ..........................................[done] (30/42) Installing: libcephfs1-10.2.1+git.1464009581.b8ee9e4-1.1 .........................................[done] (31/42) Installing: python-rados-10.2.1+git.1464009581.b8ee9e4-1.1 .......................................[done] (32/42) Installing: librgw2-10.2.1+git.1464009581.b8ee9e4-1.1 ............................................[done] (33/42) Installing: librbd1-10.2.1+git.1464009581.b8ee9e4-1.1 ............................................[done] (34/42) Installing: libradosstriper1-10.2.1+git.1464009581.b8ee9e4-1.1 ...................................[done] (35/42) Installing: python-cephfs-10.2.1+git.1464009581.b8ee9e4-1.1 ......................................[done] (36/42) Installing: python-rbd-10.2.1+git.1464009581.b8ee9e4-1.1 .........................................[done] (37/42) Installing: ceph-common-10.2.1+git.1464009581.b8ee9e4-1.1 ........................................[done] (38/42) Installing: ceph-base-10.2.1+git.1464009581.b8ee9e4-1.1 ..........................................[done] Additional rpm output: Updating /etc/sysconfig/ceph... (39/42) Installing: ceph-osd-10.2.1+git.1464009581.b8ee9e4-1.1 ...........................................[done] (40/42) Installing: ceph-mon-10.2.1+git.1464009581.b8ee9e4-1.1 ...........................................[done] (41/42) Installing: ceph-mds-10.2.1+git.1464009581.b8ee9e4-1.1 ...........................................[done] (42/42) Installing: ceph-10.2.1+git.1464009581.b8ee9e4-1.1 ...............................................[done] ses-admin:~ # su – cephadm su: user – does not exist ses-admin:~ # su - cephadm cephadm@ses-admin:~> ls bin public_html cephadm@ses-admin:~> ceph-deploy install ses-node1 ses-node2 ses-node3 [ceph_deploy.conf][DEBUG ] found configuration file at: /home/cephadm/.cephdeploy.conf [ceph_deploy.cli][INFO ] Invoked (1.5.32): /usr/bin/ceph-deploy install ses-node1 ses-node2 ses-node3 [ceph_deploy.cli][INFO ] ceph-deploy options: [ceph_deploy.cli][INFO ] verbose : False [ceph_deploy.cli][INFO ] testing : None [ceph_deploy.cli][INFO ] cd_conf : <ceph_deploy.conf.cephdeploy.Conf instance at 0x7f12cbf6cef0> [ceph_deploy.cli][INFO ] cluster : ceph [ceph_deploy.cli][INFO ] dev_commit : None [ceph_deploy.cli][INFO ] install_mds : False [ceph_deploy.cli][INFO ] stable : None [ceph_deploy.cli][INFO ] default_release : False [ceph_deploy.cli][INFO ] username : None [ceph_deploy.cli][INFO ] adjust_repos : True [ceph_deploy.cli][INFO ] func : <function install at 0x7f12cc1b0668> [ceph_deploy.cli][INFO ] install_all : False [ceph_deploy.cli][INFO ] repo : False [ceph_deploy.cli][INFO ] host : ['ses-node1', 'ses-node2', 'ses-node3'] [ceph_deploy.cli][INFO ] install_rgw : False [ceph_deploy.cli][INFO ] install_tests : False [ceph_deploy.cli][INFO ] repo_url : None [ceph_deploy.cli][INFO ] ceph_conf : None [ceph_deploy.cli][INFO ] install_osd : False [ceph_deploy.cli][INFO ] version_kind : stable [ceph_deploy.cli][INFO ] install_common : False [ceph_deploy.cli][INFO ] overwrite_conf : False [ceph_deploy.cli][INFO ] quiet : False [ceph_deploy.cli][INFO ] dev : master [ceph_deploy.cli][INFO ] local_mirror : None [ceph_deploy.cli][INFO ] release : None [ceph_deploy.cli][INFO ] install_mon : False [ceph_deploy.cli][INFO ] gpg_url : None [ceph_deploy.install][DEBUG ] Installing stable version infernalis on cluster ceph hosts ses-node1 ses-node2 ses-node3 [ceph_deploy.install][DEBUG ] Detecting platform for host ses-node1 ... [ses-node1][DEBUG ] connection detected need for sudo [ses-node1][DEBUG ] connected to host: ses-node1 [ses-node1][DEBUG ] detect platform information from remote host [ses-node1][DEBUG ] detect machine type [ceph_deploy.install][INFO ] Distro info: SUSE Linux Enterprise Server 12 x86_64 [ses-node1][INFO ] installing Ceph on ses-node1 [ses-node1][INFO ] Running command: sudo zypper --non-interactive --quiet refresh [ses-node1][INFO ] Running command: sudo zypper --non-interactive --quiet install ceph ceph-radosgw [ses-node1][DEBUG ] [ses-node1][DEBUG ] The following 35 NEW packages are going to be installed: [ses-node1][DEBUG ] babeltrace ceph ceph-base ceph-common ceph-mds ceph-mon ceph-osd ceph-radosgw FastCGI gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-cephfs python-Flask python-itsdangerous python-Jinja2 python-MarkupSafe python-rados python-rbd python-requests python-setuptools python-Werkzeug supportutils-plugin-ses [ses-node1][DEBUG ] [ses-node1][DEBUG ] The following package is not supported by its vendor: [ses-node1][DEBUG ] libxio [ses-node1][DEBUG ] [ses-node1][DEBUG ] 35 new packages to install. [ses-node1][DEBUG ] Overall download size: 47.3 MiB. Already cached: 0 B. After the operation, additional 204.1 MiB will be used. [ses-node1][DEBUG ] Continue? [y/n/? shows all options] (y): y [ses-node1][INFO ] Running command: sudo ceph --version [ses-node1][DEBUG ] ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) [ceph_deploy.install][DEBUG ] Detecting platform for host ses-node2 ... [ses-node2][DEBUG ] connection detected need for sudo [ses-node2][DEBUG ] connected to host: ses-node2 [ses-node2][DEBUG ] detect platform information from remote host [ses-node2][DEBUG ] detect machine type [ceph_deploy.install][INFO ] Distro info: SUSE Linux Enterprise Server 12 x86_64 [ses-node2][INFO ] installing Ceph on ses-node2 [ses-node2][INFO ] Running command: sudo zypper --non-interactive --quiet refresh [ses-node2][INFO ] Running command: sudo zypper --non-interactive --quiet install ceph ceph-radosgw [ses-node2][DEBUG ] [ses-node2][DEBUG ] The following 35 NEW packages are going to be installed: [ses-node2][DEBUG ] babeltrace ceph ceph-base ceph-common ceph-mds ceph-mon ceph-osd ceph-radosgw FastCGI gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-cephfs python-Flask python-itsdangerous python-Jinja2 python-MarkupSafe python-rados python-rbd python-requests python-setuptools python-Werkzeug supportutils-plugin-ses [ses-node2][DEBUG ] [ses-node2][DEBUG ] The following package is not supported by its vendor: [ses-node2][DEBUG ] libxio [ses-node2][DEBUG ] [ses-node2][DEBUG ] 35 new packages to install. [ses-node2][DEBUG ] Overall download size: 47.3 MiB. Already cached: 0 B. After the operation, additional 204.1 MiB will be used. [ses-node2][DEBUG ] Continue? [y/n/? shows all options] (y): y [ses-node2][INFO ] Running command: sudo ceph --version [ses-node2][DEBUG ] ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) [ceph_deploy.install][DEBUG ] Detecting platform for host ses-node3 ... [ses-node3][DEBUG ] connection detected need for sudo [ses-node3][DEBUG ] connected to host: ses-node3 [ses-node3][DEBUG ] detect platform information from remote host [ses-node3][DEBUG ] detect machine type [ceph_deploy.install][INFO ] Distro info: SUSE Linux Enterprise Server 12 x86_64 [ses-node3][INFO ] installing Ceph on ses-node3 [ses-node3][INFO ] Running command: sudo zypper --non-interactive --quiet refresh [ses-node3][INFO ] Running command: sudo zypper --non-interactive --quiet install ceph ceph-radosgw [ses-node3][DEBUG ] [ses-node3][DEBUG ] The following 35 NEW packages are going to be installed: [ses-node3][DEBUG ] babeltrace ceph ceph-base ceph-common ceph-mds ceph-mon ceph-osd ceph-radosgw FastCGI gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-cephfs python-Flask python-itsdangerous python-Jinja2 python-MarkupSafe python-rados python-rbd python-requests python-setuptools python-Werkzeug supportutils-plugin-ses [ses-node3][DEBUG ] [ses-node3][DEBUG ] The following package is not supported by its vendor: [ses-node3][DEBUG ] libxio [ses-node3][DEBUG ] [ses-node3][DEBUG ] 35 new packages to install. [ses-node3][DEBUG ] Overall download size: 47.3 MiB. Already cached: 0 B. After the operation, additional 204.1 MiB will be used. [ses-node3][DEBUG ] Continue? [y/n/? shows all options] (y): y [ses-node3][INFO ] Running command: sudo ceph --version [ses-node3][DEBUG ] ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) cephadm@ses-admin:~> ls bin ceph-deploy-ceph.log public_html cephadm@ses-admin:~> cat ceph-deploy-ceph.log [2016-11-07 11:37:32,854][ceph_deploy.conf][DEBUG ] found configuration file at: /home/cephadm/.cephdeploy.conf [2016-11-07 11:37:32,854][ceph_deploy.cli][INFO ] Invoked (1.5.32): /usr/bin/ceph-deploy install ses-node1 ses-node2 ses-node3 [2016-11-07 11:37:32,854][ceph_deploy.cli][INFO ] ceph-deploy options: [2016-11-07 11:37:32,854][ceph_deploy.cli][INFO ] verbose : False [2016-11-07 11:37:32,854][ceph_deploy.cli][INFO ] testing : None [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] cd_conf : <ceph_deploy.conf.cephdeploy.Conf instance at 0x7f12cbf6cef0> [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] cluster : ceph [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] dev_commit : None [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] install_mds : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] stable : None [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] default_release : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] username : None [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] adjust_repos : True [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] func : <function install at 0x7f12cc1b0668> [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] install_all : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] repo : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] host : ['ses-node1', 'ses-node2', 'ses-node3'] [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] install_rgw : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] install_tests : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] repo_url : None [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] ceph_conf : None [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] install_osd : False [2016-11-07 11:37:32,855][ceph_deploy.cli][INFO ] version_kind : stable [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] install_common : False [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] overwrite_conf : False [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] quiet : False [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] dev : master [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] local_mirror : None [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] release : None [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] install_mon : False [2016-11-07 11:37:32,856][ceph_deploy.cli][INFO ] gpg_url : None [2016-11-07 11:37:32,856][ceph_deploy.install][DEBUG ] Installing stable version infernalis on cluster ceph hosts ses-node1 ses-node2 ses-node3 [2016-11-07 11:37:32,856][ceph_deploy.install][DEBUG ] Detecting platform for host ses-node1 ... [2016-11-07 11:37:33,075][ses-node1][DEBUG ] connection detected need for sudo [2016-11-07 11:37:33,221][ses-node1][DEBUG ] connected to host: ses-node1 [2016-11-07 11:37:33,221][ses-node1][DEBUG ] detect platform information from remote host [2016-11-07 11:37:33,256][ses-node1][DEBUG ] detect machine type [2016-11-07 11:37:33,260][ceph_deploy.install][INFO ] Distro info: SUSE Linux Enterprise Server 12 x86_64 [2016-11-07 11:37:33,260][ses-node1][INFO ] installing Ceph on ses-node1 [2016-11-07 11:37:33,263][ses-node1][INFO ] Running command: sudo zypper --non-interactive --quiet refresh [2016-11-07 11:37:33,491][ses-node1][INFO ] Running command: sudo zypper --non-interactive --quiet install ceph ceph-radosgw [2016-11-07 11:37:33,758][ses-node1][DEBUG ] [2016-11-07 11:37:33,758][ses-node1][DEBUG ] The following 35 NEW packages are going to be installed: [2016-11-07 11:37:33,758][ses-node1][DEBUG ] babeltrace ceph ceph-base ceph-common ceph-mds ceph-mon ceph-osd ceph-radosgw FastCGI gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-cephfs python-Flask python-itsdangerous python-Jinja2 python-MarkupSafe python-rados python-rbd python-requests python-setuptools python-Werkzeug supportutils-plugin-ses [2016-11-07 11:37:33,758][ses-node1][DEBUG ] [2016-11-07 11:37:33,758][ses-node1][DEBUG ] The following package is not supported by its vendor: [2016-11-07 11:37:33,758][ses-node1][DEBUG ] libxio [2016-11-07 11:37:33,758][ses-node1][DEBUG ] [2016-11-07 11:37:33,759][ses-node1][DEBUG ] 35 new packages to install. [2016-11-07 11:37:33,759][ses-node1][DEBUG ] Overall download size: 47.3 MiB. Already cached: 0 B. After the operation, additional 204.1 MiB will be used. [2016-11-07 11:37:33,759][ses-node1][DEBUG ] Continue? [y/n/? shows all options] (y): y [2016-11-07 11:37:44,565][ses-node1][INFO ] Running command: sudo ceph --version [2016-11-07 11:37:44,683][ses-node1][DEBUG ] ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) [2016-11-07 11:37:44,683][ceph_deploy.install][DEBUG ] Detecting platform for host ses-node2 ... [2016-11-07 11:37:44,876][ses-node2][DEBUG ] connection detected need for sudo [2016-11-07 11:37:45,016][ses-node2][DEBUG ] connected to host: ses-node2 [2016-11-07 11:37:45,017][ses-node2][DEBUG ] detect platform information from remote host [2016-11-07 11:37:45,055][ses-node2][DEBUG ] detect machine type [2016-11-07 11:37:45,060][ceph_deploy.install][INFO ] Distro info: SUSE Linux Enterprise Server 12 x86_64 [2016-11-07 11:37:45,060][ses-node2][INFO ] installing Ceph on ses-node2 [2016-11-07 11:37:45,062][ses-node2][INFO ] Running command: sudo zypper --non-interactive --quiet refresh [2016-11-07 11:37:45,335][ses-node2][INFO ] Running command: sudo zypper --non-interactive --quiet install ceph ceph-radosgw [2016-11-07 11:37:45,602][ses-node2][DEBUG ] [2016-11-07 11:37:45,602][ses-node2][DEBUG ] The following 35 NEW packages are going to be installed: [2016-11-07 11:37:45,602][ses-node2][DEBUG ] babeltrace ceph ceph-base ceph-common ceph-mds ceph-mon ceph-osd ceph-radosgw FastCGI gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-cephfs python-Flask python-itsdangerous python-Jinja2 python-MarkupSafe python-rados python-rbd python-requests python-setuptools python-Werkzeug supportutils-plugin-ses [2016-11-07 11:37:45,602][ses-node2][DEBUG ] [2016-11-07 11:37:45,603][ses-node2][DEBUG ] The following package is not supported by its vendor: [2016-11-07 11:37:45,603][ses-node2][DEBUG ] libxio [2016-11-07 11:37:45,603][ses-node2][DEBUG ] [2016-11-07 11:37:45,603][ses-node2][DEBUG ] 35 new packages to install. [2016-11-07 11:37:45,603][ses-node2][DEBUG ] Overall download size: 47.3 MiB. Already cached: 0 B. After the operation, additional 204.1 MiB will be used. [2016-11-07 11:37:45,603][ses-node2][DEBUG ] Continue? [y/n/? shows all options] (y): y [2016-11-07 11:37:56,699][ses-node2][INFO ] Running command: sudo ceph --version [2016-11-07 11:37:56,819][ses-node2][DEBUG ] ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) [2016-11-07 11:37:56,820][ceph_deploy.install][DEBUG ] Detecting platform for host ses-node3 ... [2016-11-07 11:37:57,028][ses-node3][DEBUG ] connection detected need for sudo [2016-11-07 11:37:57,173][ses-node3][DEBUG ] connected to host: ses-node3 [2016-11-07 11:37:57,173][ses-node3][DEBUG ] detect platform information from remote host [2016-11-07 11:37:57,210][ses-node3][DEBUG ] detect machine type [2016-11-07 11:37:57,215][ceph_deploy.install][INFO ] Distro info: SUSE Linux Enterprise Server 12 x86_64 [2016-11-07 11:37:57,216][ses-node3][INFO ] installing Ceph on ses-node3 [2016-11-07 11:37:57,218][ses-node3][INFO ] Running command: sudo zypper --non-interactive --quiet refresh [2016-11-07 11:37:57,494][ses-node3][INFO ] Running command: sudo zypper --non-interactive --quiet install ceph ceph-radosgw [2016-11-07 11:37:57,762][ses-node3][DEBUG ] [2016-11-07 11:37:57,762][ses-node3][DEBUG ] The following 35 NEW packages are going to be installed: [2016-11-07 11:37:57,762][ses-node3][DEBUG ] babeltrace ceph ceph-base ceph-common ceph-mds ceph-mon ceph-osd ceph-radosgw FastCGI gperftools libboost_iostreams1_54_0 libboost_program_options1_54_0 libboost_random1_54_0 libcephfs1 libibverbs1 libleveldb1 librados2 libradosstriper1 librbd1 librdmacm1 librgw2 liburcu0 libxio lttng-ust python-cephfs python-Flask python-itsdangerous python-Jinja2 python-MarkupSafe python-rados python-rbd python-requests python-setuptools python-Werkzeug supportutils-plugin-ses [2016-11-07 11:37:57,762][ses-node3][DEBUG ] [2016-11-07 11:37:57,762][ses-node3][DEBUG ] The following package is not supported by its vendor: [2016-11-07 11:37:57,762][ses-node3][DEBUG ] libxio [2016-11-07 11:37:57,762][ses-node3][DEBUG ] [2016-11-07 11:37:57,762][ses-node3][DEBUG ] 35 new packages to install. [2016-11-07 11:37:57,762][ses-node3][DEBUG ] Overall download size: 47.3 MiB. Already cached: 0 B. After the operation, additional 204.1 MiB will be used. [2016-11-07 11:37:57,762][ses-node3][DEBUG ] Continue? [y/n/? shows all options] (y): y [2016-11-07 11:38:08,867][ses-node3][INFO ] Running command: sudo ceph --version [2016-11-07 11:38:08,987][ses-node3][DEBUG ] ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) cephadm@ses-admin:~> ceph -v ceph version 10.2.1-112-gb8ee9e4 (b8ee9e4007f0443ef50deb1a691c3ea8bd0a11fe) cephadm@ses-admin:~> ceph-deploy new ses-node1 [ceph_deploy.conf][DEBUG ] found configuration file at: /home/cephadm/.cephdeploy.conf [ceph_deploy.cli][INFO ] Invoked (1.5.32): /usr/bin/ceph-deploy new ses-node1 [ceph_deploy.cli][INFO ] ceph-deploy options: [ceph_deploy.cli][INFO ] username : None [ceph_deploy.cli][INFO ] verbose : False [ceph_deploy.cli][INFO ] overwrite_conf : False [ceph_deploy.cli][INFO ] quiet : False [ceph_deploy.cli][INFO ] cd_conf : <ceph_deploy.conf.cephdeploy.Conf instance at 0x7fbd48a4df80> [ceph_deploy.cli][INFO ] cluster : ceph [ceph_deploy.cli][INFO ] ssh_copykey : True [ceph_deploy.cli][INFO ] mon : ['ses-node1'] [ceph_deploy.cli][INFO ] func : <function new at 0x7fbd48a285f0> [ceph_deploy.cli][INFO ] public_network : None [ceph_deploy.cli][INFO ] ceph_conf : None [ceph_deploy.cli][INFO ] cluster_network : None [ceph_deploy.cli][INFO ] default_release : False [ceph_deploy.cli][INFO ] fsid : None [ceph_deploy.new][DEBUG ] Creating new cluster named ceph [ceph_deploy.new][INFO ] making sure passwordless SSH succeeds [ses-node1][DEBUG ] connected to host: ses-admin [ses-node1][INFO ] Running command: ssh -CT -o BatchMode=yes ses-node1 [ses-node1][DEBUG ] connection detected need for sudo [ses-node1][DEBUG ] connected to host: ses-node1 [ses-node1][DEBUG ] detect platform information from remote host [ses-node1][DEBUG ] detect machine type [ses-node1][DEBUG ] find the location of an executable [ses-node1][INFO ] Running command: sudo /bin/ip link show [ses-node1][INFO ] Running command: sudo /bin/ip addr show [ses-node1][DEBUG ] IP addresses found: ['192.168.100.11', '192.168.200.11'] [ceph_deploy.new][DEBUG ] Resolving host ses-node1 [ceph_deploy.new][DEBUG ] Monitor ses-node1 at 192.168.100.11 [ceph_deploy.new][DEBUG ] Monitor initial members are ['ses-node1'] [ceph_deploy.new][DEBUG ] Monitor addrs are ['192.168.100.11'] [ceph_deploy.new][DEBUG ] Creating a random mon key... [ceph_deploy.new][DEBUG ] Writing monitor keyring to ceph.mon.keyring... [ceph_deploy.new][DEBUG ] Writing initial config to ceph.conf... cephadm@ses-admin:~> Creation de pool pool name number of placement groups : (nber of OSD * 100 ) / nber of replicas pool size : 2,10 g take 20 g of storage and 20 g of netw transfert pool size : 3,10 g take 30 g of storage and 30 g of netw transfert => il vaut ;ieux bcp de petits data pool plutot qu un gros rados attaque en direct le pool sans passer par la couche osd default, replicate all datas => full replication, 3x stockage et bande passante RDB Storage pour avoir du block storage, il faut creer une image d abord puis ;appe en block device format1 or 2 => 2 support snapshots rbd create, puis map pour connect si besoin, faire le pool avant rbd create -p poolname rdbimagename --size xxx --image format 2 size en mb par defaut rbd list cephadm@ses-admin:~> ceph osd map test myobj osdmap e23 pool 'test' (1) object 'myobj' -> pg 1.c3ca3d86 (1.6) -> up ([2,1], p2) acting ([2,1], p2) cephadm@ses-admin:~> ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.04376 root default -2 0.01459 host ses-node1 0 0.01459 osd.0 up 1.00000 1.00000 -3 0.01459 host ses-node2 1 0.01459 osd.1 up 1.00000 1.00000 -4 0.01459 host ses-node3 2 0.01459 osd.2 up 1.00000 1.00000 cephadm@ses-admin:~> ceph osd pool set test size 3 set pool 1 size to 3 cephadm@ses-admin:~> ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.04376 root default -2 0.01459 host ses-node1 0 0.01459 osd.0 up 1.00000 1.00000 -3 0.01459 host ses-node2 1 0.01459 osd.1 up 1.00000 1.00000 -4 0.01459 host ses-node3 2 0.01459 osd.2 up 1.00000 1.00000 Mapping pour utilisation en direct persistence de mapping se fait dans fstab cephadm@ses-admin:~> rbd create -p block-pool block-storage --size 1024 cephadm@ses-admin:~> rbd -p block-pool info block-storage rbd image 'block-storage': size 1024 MB in 256 objects order 22 (4096 kB objects) block_name_prefix: rbd_data.108f238e1f29 format: 2 features: layering flags: cephadm@ses-admin:~> sudo su - ses-admin:~ # cat /etc/fstab UUID=a8cecc6a-ed55-45ec-9092-08cccd1d1fa5 swap swap defaults 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb / btrfs defaults 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /home btrfs subvol=@/home 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /opt btrfs subvol=@/opt 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /srv btrfs subvol=@/srv 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /tmp btrfs subvol=@/tmp 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /usr/local btrfs subvol=@/usr/local 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/crash btrfs subvol=@/var/crash 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/lib/named btrfs subvol=@/var/lib/named 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/log btrfs subvol=@/var/log 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/opt btrfs subvol=@/var/opt 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/spool btrfs subvol=@/var/spool 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /var/tmp btrfs subvol=@/var/tmp 0 0 UUID=f809d9df-cc52-43e0-a42c-3f2c8ee680eb /.snapshots btrfs subvol=@/.snapshots 0 0 ses-admin:~ # rbd map -p block-pool --image block-storage /dev/rbd0 ses-admin:~ # rbd showmapped id pool image snap device 0 block-pool block-storage - /dev/rbd0 ses-admin:~ # ls /dev/rbd* /dev/rbd0 /dev/rbd: block-pool Snapshot sans overhead rbd snap (etc) Copy on write snapshot layering, i;age au for;at 2 obligatoirement mais les snapshots sont alors indispensables, i faut les proteger avec la fonction lock rfc3720 for iscsi json configurqtion quthenticqtion to iscsi authentication https://www.suse.com/docrep/documents/kgu61iyowz/suse_enterprise_storage_3_and_iscsi.pdf ses-node3:~ # targetcli ls o- / ..................................................................................................... [...] o- backstores .......................................................................................... [...] | o- fileio ............................................................................... [0 Storage Object] | o- iblock ............................................................................... [1 Storage Object] | | o- iscsi .................................................................. [/dev/rbd/rbd/iscsi activated] | o- pscsi ................................................................................ [0 Storage Object] | o- rbd .................................................................................. [0 Storage Object] | o- rd_mcp ............................................................................... [0 Storage Object] o- ib_srpt ....................................................................................... [0 Targets] o- iscsi .......................................................................................... [1 Target] | o- iqn.2003-01.org.linux-iscsi.ses-node3.x8664:sn.76494aa74ebc ..................................... [1 TPG] | o- tpg1 ........................................................................................ [enabled] | o- acls ....................................................................................... [0 ACLs] | o- luns ........................................................................................ [1 LUN] | | o- lun0 .......................................................... [iblock/iscsi (/dev/rbd/rbd/iscsi)] | o- portals .................................................................................. [1 Portal] | o- 192.168.100.13:3260 ........................................................... [OK, iser disabled] o- loopback ...................................................................................... [0 Targets] o- qla2xxx ....................................................................................... [0 Targets] o- tcm_fc ........................................................................................ [0 Targets] o- vhost ......................................................................................... [0 Targets] erasure code profile une sorte de qos pour econo;iser du reseau pour limiter les controles d integrite chaque erreur part dans une sorte de poubelle cephadm@ses-admin:~> ceph osd erasure-code-profile get default k=2 m=1 plugin=jerasure technique=reed_sol_van exemple k+m (10+6), on peut perdre 6 sur 16 disks (totalite des disques) 10 disks requis prend 60% de capacite attention aux perf, se rapproche d un raid6 si erasure profile fixe, ne peut pas etre change utile sur des donnes chaudes/donnees froides/cout de stockage ceph status : look at placement group ex : recovering en bas de page monitor : health, mon quorum, osd status, pg status, full disk, nodes status => ceph health => ceph status cephadm@ses-admin:~> ceph -w cluster 9a5b2edf-4d00-4b46-a010-3420d96450e5 health HEALTH_WARN too many PGs per OSD (408 > max 300) monmap e3: 3 mons at {ses-node1=192.168.100.11:6789/0,ses-node2=192.168.100.12:6789/0,ses-node3=192.168.100.13:6789/0} election epoch 6, quorum 0,1,2 ses-node1,ses-node2,ses-node3 osdmap e57: 3 osds: 3 up, 3 in flags sortbitwise pgmap v3256: 408 pgs, 15 pools, 70949 kB data, 505 objects 322 MB used, 45724 MB / 46046 MB avail 408 active+clean ceph calamari backend, romana frontend inclus avec suse enterprise storage install calamari puis deploy --master monitoring-mode alaister@suse.com

Notes Sysadmin Days #6 - Paris

Olivier Duquesne aka DaffyDuke — 2016-02-18T14:20:00Z

*on est pas là pour vendre de la magie, 8 ans de conf* # sysadmin de combat (FRED DE VILLAMIL) attention au budget divergence de priorité => "redonner confiance dans l'infrastructure" 50/50 scrum+run, planif ve pm, daily standup mach. café astreinte tournante, toujours donner une date pour le delivery les dev font la MEP via jenkins+ansible (=> java / go) monte une équipe sénior (pour ne pas faire de micromanagement, montée en compétence rapide) profil cher entre 50/90 attention communication => slack incidents (uniqt chef du support, transparence, sans alaramant, ETA précis si possible) reporting hebdo de 3/4 slides (contexte d'une période de crise d'un an pour remonter un cluster galera), nb incidents, heures d'inter, .... et ETA projets découverte : monitoring, nmap+ssh+facter "pour voir" dans un CSV / tcpdump sur des fw/ansible , attention puppet/ansible début: rester humble, laisser ce qui marche et ceux qui savent faire, test de redémarrage de services "pour voir", "se concerter sur ce qu'on ne connait pas et qui marche plutôt que sur ce qu'on connait mais qui ne marche pas" Documentation (interne Zabbix) Attention aux env. non maîtrisés Dificulté de reprises d'unfra montée par des dev qui "pensent" différemment : un mach/un service pas de vhost/ .... ## questions confluence, gitlab (markdown) essayer de déléguer SAS au possible "tu bosses le week-end" pour tenir tes ETA besoin d'être capable de dire "non *plus tard*" jira pour sprints (redmine abandonné), "pager duty" à venir Gandi => Trello pour daily meeting revue de doc/code review par gitflow troll AWS : utilisation d'autoscaling pour les machines qui tombent toute seule troll OVH : couche ethernet revue et corrigée # Grid 5000, Lucas Nussbaum, a hpc, big data, INRIA, université de Lorraine Debian Project Leader de 2013,15 Licence Pro Adm. Sys Réseaux App. Logiciels Libres Recherche sur expérimentation scientifiques essaie de fournir une infra de qualité comparable aux autres composants de recherche (biologie, physique, ....) renater 10g 10 sites, 25 cluster, 1000 nodes, 8000 cores 550 personnes difficulté de cloud public (difficulté de monitoring, placement, perf) utilisation de BonFIRE (infra dedié observation) bare metal as a service, reconfigurable à la demande desc. env. en json avec archivage de conf utilisation outil maison g5-checks pour comparer desc stockée avec desc générée (appel OHAO, ethtool, ....) besoin GPU, wattmetter, software, garder stable création de kadeploy (bare metal, hardware as a service), boot en PXE, 200 nodes en 5 min(car deux reboots hardw) KaVLAN pour tagguer les réseaux sur les équipements réseau http://kamaleon.imag.fr : generation d'appliance (avec utilisation de cache des images étalonné / archivées) http://distem.gforge.nria.fr : utilisation de LXC pour quotas de CPU/Core Utilisation Charm++ lb HPC avec distem "Ralentir le temps pour que le CPU et le réseau aille plus vite" : Time Keeper (facteur de dilatation du temps de LXC) sous Linux ou dilatation du temps (DieCast sous Xen) time shifting en roadmap monitoring en mode découverte avec Ganglia + sondes réseau/DPU/... utilisateurs = doctorants, étudiants M2, ...., => shell => création d'une API d'orchestration XPFLOW env. unique au monde de support d'expérimentations ## questions pas de pb sur mesure 1/sec sur switchs Ironic (OpenStack) vs Kadeploy (plus vieux, plus de fonctions) criu.org => checkpointing de jobs => appeler Master I2L pour reorienter AsminSys si possible # ElasticSearch chez Synthesio par Fred De Villamil Synthesio: parcours de site social, enrichissement de données 271To de cluster, 7 To de RAM, 3 cluster, 116 serveurs, 60 milliards de doc indexés Elasticsearch : moteur de rechcerche distribué basé sur Lucene, base sur "Solr on steroid", ancien nom Comment : 1 index, 512 chards avec un routage au mois (au lieu de la semaine nitialement), 47 deian en java 1.8 => dashboard1GC / GCPausIntervalMillis=1000 / InitiatingHeapOccupancyPercent=35 => plus d'out of the world => tuning field data : limit ) 80% sur breaker, 30% de cache size sur la heap, expire 1 minute : options deprecated dans le futur Déconseillé par la doc ES, pas vu de pb de perf, plus de perte du cluster step2, 1 index par dashbpoard pour 10 milliards de documents 2 clusters iso en ES 1.7.5 (1.7.4 bug de memoire grave) 2 VM ) 64 G de RAM 3 master, 3 de RAM 0 nodesà 32 G RAM 1 inde par dashboard, 1 shared => versionning du mapping possible grace à Baldur Baldur = proxy nginx en LUA (récup cluster + id de mapping en base MySQL) => modification de mapping se fait dans la base mysql alors que les data sont en cours de traitement coté cluster et donc création de milliers de segments lucene création de plus de seglents que de suppression, donc les index peinaient à être construit => otpim en continu sur ordre deleted + sur index x-1 => utilisation de "rack awareness" ES : blocage d'allocation pendant un A/R par rack Nouveau cluster : 70 serveurs 36 index 50 milliards de documents 120 T de données, 160 T de capa, 1 idx/mois, 30 shards 2 query nodes 31 G 62 data node en Xeo D, 64 G RAM, 3,2 T RAM 3 cluster galera et un cluster ES dans un kafka indexer en Go sur 8 machine et doit récupérer une queue par an sur le data node pour l'idexation sans passer par le query pas de replicat pendant l'indexation pour diminuer les ressources ES tente de mettre les requetes en cace sur les requettes en lectures (pb de cache si range , utilisation de YourKit pour debugger la heap au crash dump (à cette epoque 1.7.4 => passer en 1.7.5 !) => désactivation des caches + parallélisation des requetes par index next : 50 millions de doc/jour (plus de sphynx, maintenant utilisation de percolation = indexation inversée dans ES) 35000 rq à tester, en percolation on a une estimation de 1700 milliards de req => routage sur la langue des documents , objectif 100 000 req/sec ## questions ES en 2 ? pb de réécriture de query (DSL de sphynx vers ES déjà fait, à refaire pour passer en ES2) pas d'étude d'autre soft par compétence monotiring ; marvelpour le temps réel (marvel pour monitorer + cluster de monitoring de marvel lui-même) ; le reste est graffé par Zabbix sauvegarde / archivage ? non car toute la donnée brute est dans mysql (25 To dans un Galera), ES n'est pas prévu pour stocker, ce n'est pas MongoDB snapshot ? S3 ou N/Z/.../FS : 10 To trop gros pour gérer des snapshots Utilisation de plugin d'analyse linguistique tels stemmer chiffrement inter noeud : non => étude FS chiffré pas d'ACL sur ES unicast conso de disques SSD de plu sen plus importante OVH ; coupure électrique ou réseau : systeme de maitre / quorum => donc pas de soucis sur ES. plus de corruptions de données depuis la 1.0 # Puppet at Gandi, Aurélien Rouhemont, Arthur Gautier Equipe de 15 personnes puppet = QUE un gest de conf = framework, pas grand chose out of the box pas un orchestrateur, pas la "silver bullet", ce n'est pas léger Gandi, pourquoi ? pull model (se fait pas violé par un SSH de l'externe) ; promise theory (mark de cfengine), en 2009 pas grand chose, utilisation master , DSL simple, pas besoin de connaître le ruby, descriptif pour aller vers un état final (si déclaration de dépendances), populaire Configuration Management chez Gandi : avant 2009 : Makefile, package, Awk, 2009 : premier repo puppet SVN alors que personne ne faisait de ruby 2010 : pas de module, un site.pp 2011 : réflexions hiera et template (module + conf. extérieure) 2013 : pas d'upgrade puppet 3.x possible 2014 : génération de monitoring dans puppet (il génère la conf pour la pf de monitoring : nagios, thrunk) 2015 : en 10 jours, réécriture de 250 modules puppet en 3.7 2016 : orchestration Ouverture aux développeurs, merge request, depuis 2013 Comment ENC : MySQL + insertions + Perl => utilisation d'un YAML à partir de 2015 Facts Matters : meta comm eun autre pour définir des groupes de serveurs, ce n'est pas natif, il faut penser à la faire, ,notion de flavor = sous groupe de farm savoir si un module est utilisé => au début pas de forge puppet (coup d'entrée assez cher pour du non ruby fluent), exemple42 pas dispoi à l'époque, création d'un templae de module : init.pp, install.pp (packages uniq), config.pp, files.pp, cron.pp, service.pp : conv. de nommage de variable depuis hiera dans l'init.pp (cron.pp : gestion de cron au lien symbolique) un rep temlate par flavor coding style human readable !, code portable, utilisation de best practices, ex files = collection d'object, pas un objet 20 à 60% de perf mieux sur gros catalogues de file sjusqu'en 2.7 hiera as datasource nodes / farm, datasource, room, etc ... puppet vanishment history à voir sur puppetlabas dynamic variaable scoping sad panda => tig (arbre git) => 250 branches git : taken.owner, taken.done pour ne pas se marcher dessus datatypes mieux codées avec stdlib hiera merging policy => le change est devenu merge (ex sur acl) gitlab pour repo couplé à un jenkins puppet linting + rule du gandi module layout + syntax validation + yaml validation + erb syntax validation passage 3.7 a uniformisé le niveau d'admin puppet puppet environment="mergerequest" utilisation d'un git merge --no-comit jenkins appelle le puppet-lint erb -P -x -T file.rb pupeet-db => json => jinja => nagios mcollective fait le puppet run mcollective joli mais fragile version web de hiera => hieraviz pour lire la base hiera : idée écrire depuis hieraviz https://github.com/gandi/hieracles Etude d'impact en cours alias puppet status, puppet lock + motif + Conclusion puppet n'est pas un orchestrateur => ansible ? abandonner le tas de yaml avec une API / CMDB ## question reporting : foreman, mais pas plus que çà envisagé : consul ? hitop (en php) ? modules fait maison uniquement pour l'instant puppet4 : pb des modules tout fait puppet enterprise : idem, pas de forge dump d'inventaire à partir du DNS, attention aux alias itop trop gros par rapport aux besoins un puppet master de production, utilisation des environnements plusieurs run pour passage OK parfois et toléré => voir le "puppet virtual nodes" pour le test de code puppet # Blocage dynamique de pages web (Frédéric Vannière, planet-work.com) NGINX/LUA 400 machines, virtu, Freebsd pour les backup 10000 sites, 30% wordpress => spam, phishing stockage sur Netapp en NFSv3 Archi NGINX en front reverse proxy (apache tient peu la charge sur ce besoin), statiques hébergées en front Solution OpenResty = module NGINX + LUA Clé valeur de blacklist via DNSBL blaclist.conf : conf dnsbl gère le blocage + deblocage par mot de passe pour l'accès client Détection : gestion des logs via rsyslog centralisé (en rfs5424) - stack ELK : (logstash 1.4 fragile aux caractères mal encodés) - tests HekaD (projet Mozilla, en go, multithreads, sandbox LUA) (écrit dans un elasticsearch) : attention une fois le msg traité, plus d'altération possible. Prévu pour la métrologie : collectd->aggreg->influxd => création d'un flitre sandbox LUA => openresty < 3 avec validation auto Let's Encrypt : script python tiers (cloudflare) pour vérifier les expiation http://pw.fr recrute sur Paris / Rennes (l'an prochain) 5 techos "on est pas là pour vendre de la magie, 8 ans de conf" ## questions Quid de la rotation : perte possible mais NGNINX, permi Pas de pb de perf sauf sur ES # Gestion des services par Gandi (Fabrice Daroussin) présentation,attention aux mélanges watchman launchd systemd openrc upstart (tous vivant) init historique : petit, process pere de tous les processus, ne gere pas la gestion des services (inittab ou ttys de freebsd) puis délègue à sysvinit, rcng (freebsd), rc (openbsd) Mais pas de cycle de vie, pas de moyen que le service est rendu, difficile d'assurer la cohérence entre les scripts d'init, pas de gestion de ressources (RAM, CPU, sandbox de l'OS, ....) supervision par un pid uniquement (souvent loupé pour lemonitoring si double fork) gestion des dépendances faibles framework, souvent en shell (posix, bash, zsh) ex: Dabian Dash gestion d'erreur en shell pas simple car trap etc .... complexe à isoler (/etc/init.d/truc start) (mais pb sur les variables d'enrionnement) => comman de service pour contrôler variables d'environnement (présente sous Linux, FreeBSD, systemd) complexe pour cohérence multi OS (même multi Linux) pas de gestion de performances ni de surveillance de processus fiabilité aléatoire du status (souvent que le père) pas de gestion d'évènementielle (ex cupsd uniquement si printer) ex : inetd evenement => udev => script de service => latence pas de fault management (ex les workers apaches en failed) difficile de faire un démon : user non privilégié, attention au chroot sans chdir, refaire un setrlimit (mais chacun veut le faire) (s attention aux parents laxistes qui abandonnent leurs enfants (apache et fiston) peu de parallèle de service, trous dans les logs Solutions : PID via process descriptor FreeBSD 10.0, Linux 4.1 : polling de race reapers (garder les trace des fils) : Linux 3.4 (dbus), Solaris 10 (contracts), FreeBSD10.2, Dragonfly 4.0 : un service pour démarrer les services apache Services : Génerer les services via sandboxing Réactivité : devd envoi sans parser tous les scripts Format pas important ; description yaml, json, ini, ....mais la description est importante Gestion des sockets pour séparation de privilèges, ex bufferisation de logs si syslog cassé Utiliser un IPC (séparer les taches) => remplacer init ? pas utile, aucun service actuel ne gère toutes les demandes vues ici ? SMF (Solaris) gère le monitoring (mais Over engineer) a conservé init, cron, ...., fault management Références : do_command.c de Paul Vixie Solaris Service Management Facility Modern System Startup ## questions systemd : approche, manquant à SMF : le pid pere est encore crucial, pas encore de tracabilité de fils car utilise les cgroups # Linux Crashdump analysis - Adrien Mahieux, github.com/Saruspete Kernel Recipes 2015 crashdump / kdump : snapshot de la mémoire en cours, principalement Linux, sysadmin se fait via kexec & panic 64 à 512 M de RAM vmware : suspend , vmss2core libvirt : virsh dump guest Get : kernel config KEXEC=y .... bootoption : crashlernel=auto (auto = X@Y réécri) indiquer un masque sur pages privées, userland, .... dump entre 100M et 2G si utilisation intensive impi power diag (NMI via IPMI) virsh inject-nmi guest attention au kernel.unknown_nmi_panic=1 => car le code NMI n'est pas le même pour tous les constructeurs mais peut etre en conflit avec ooprofile OOM : vm.panic_on_oom=1 Analysis : crash via Dave Anderson de RedHat (gdb) RedHat : debuginfo-install kernel Debian : apt-get install linux-image-$'uname -r)_dbg même commandes que dans gdb (bt ....) Live kretprobes : CONFIG_STRICT_DEVMEM savoir si on sait lie sur /dev/mem OpenGrok fast code source browser voir makedumpfile sur chitranshi fence kdump sur ovirt.org ## questions un redémarrage via kexec, puis un redémarrage normal # Performance Analysis, fro msilicon to algorithm (microsecund hunter) sysadmin : utiliser des algo pour contourner des pb hardware, tuning d'appli, .... besoin de bien connaître le client, protocoles, .... attention au ratio gain / coût Souvent regarder côté application pour optim' Comment ça marche ? balance d'éléments storage lent : ajout redahead ou RAM network : offload, DMA RAM slower than CPU, add L1/L2/L3 cache video : utilisation GPU .... memory management : méchanismes de segmentation MMU : @locique : segmentation => virtual pagination => physical allocation kernel linux overcommit (resident 100m versus allocation 17 Go) => overcommit attention OOMKiller qui libère dec RAM (algo plu sou moins heureux), score tunable via /proc/<PID>/oom_score/adj buddy allocator : ex plusieurs giga lobres mais mem fragmentée, car meme pas utilisable si pas contigue => utilisation du SLAB cache pour limite la fragmentation : CPU : kernel scheduler, via la variable HZ ticks geneère les jobs : context switch userland => syscall => libc (wrappers) open,malloc,mmap => gates : possible d'accéléer via VDSO (gettimeofday, ....) Réseau : ethtool -g <int> : taille du ring buffer (DMA) en RAM et gnère une interruotion optim harware (plusieurs queue sur carte 10 G), voir le blog de Claude Feder Storage IO sont en syscall, scheduler d'IO à observer coherence en terme de cohrence ZFS et BTRFS pas de VFS, ext/xfs/ oui .... puis elevator donne request queue : cfq defaut), deadline : garanti le wait (databases) , noop (SSD) mmap : bcp overhead mais rapide Mesurer 'Use method) : Brendan Gregg Netflix (auteur de netflix) utilization actuelle, quelle est la saturation, quelles sont les erreur sampling : ps, top, perf tracing : auditd, ktrace, systemtap, gdb conter : intel pcm, numastat, user feedback rappel des slides netflix Quoi faire rapide, robuste, pas cher, jamais possible d'avoir les 3 * latence : tps de traitement de signal : isolcpu, ou nohz_full (desactiv les tick, attention à irqbalance => attention à la dacdrer ou le désactiver , / désactiver le coalescing / attention au readahead, penser à le désactiver, compression (ZFS: cout een CPU mais économise en stockage) fibre optique c'est lent : sniperinmahwah.wordpress.com (hyperthreading haute fréquence) => la lumière est rapid dans le vide uniquement * débit : difficile car lié à chaque comppsant disk, réseau, aute (ex: chunk size, jumbo fram, en gros plus il y a de RAM, mieux ça marche) * jitter : industriel, realtime, moteur carburant / air, précis et fiable, ex un thread kernel au lieu d'un thread kernel par CPU : isolcpu, nohz_full, ... A la recherche des problèmes perf et les flamegraph version de pagefault ou diff flamegraph systemtap : utilise les debuginfo comme crashdump : génère du code C et injecte dans le kernel Et le hardware * CPU Interl PCM (performance counter monitor) intel.com/ peformance ... MSR : Model Specific Register: module msr pour la RAM, trop tard, maintenant c'est le CPU qu igère on peut avoir les erreurs ECC avec dmidecode * NIC : DPDK OpenFabric : kernel bypass; Infinibands écrit dans la RAM des voisins ## questions moyen de voir si c-state activé ou pas : cpufreq (cpupower monitor) i7z : lit les données relatives à la freq du CPU powertop : applis qui généré interruptions, wakeup tuned : fait le job, mais fait trop de chose qu'o ne veut pas forcément si processeur change de socket, pas forcément besoin de RAM en RAID, mais pb sur mémorie cache CPU, donc intérêt à garder les proces sur le même coeur (isolcpu) FreeBSD : équivalences ? voir la map de Brendan Greg existe aussi pour Solaris ## Retour d'expérience sur un scan de détection de malware sur une infrastructure hébergeur, par Julien Reveret, NBS Systems Projet d'actualité : nettoyage du canal saint-martin (pneus, matelas, ....), => machines clients idem Dev. internes : Julien Voisin, PHP-malware-finder basé sur yara (détecter les malwares les plus courants uniquement) ex. beaucoup de bruit, puis analyse par un humain, un seul fichier avec malware autres faux positifs => identification par hash cryptographique : liste blanche à partir des faux positifs => poussé sur github.com/nbs-system/php-malware-finder Résultats : machines avec infections dormantes (une dizaine), des faux positifs ; du faux positif, de la whitelist et finalement trouvé un webshell alors qu'il était PCI-DSS ! ; un module tiers magento ressemblant à un malware ; divers webshell Beaucoup de craptographie chez les développeurs PHP :-) Temps de traitement : 7 heures pour 100 machines en NFS ## questions A t'on le droit d'ouvrir les fichiers des clients => ici oui, audit de code déjà prévue Netapp : utilsation de fpolicy sur fichiers modifiés ? => à voir supervision ? pas encore # Nouveautés de FreeBSD 11 Baptsite Daroussin (probablement inclut en 10.3 beta) fin ia64, ajout arm64 et risc-V ; improve ARM : dtrace & more CloudABI = format binaire cross OS sandboxé mais dépendant de l'arch, enregistré au niveau de posix pour avoir le numéro elf associé, toolchain : lldb par défaut amd64 migration binutils vers Elftoolchain (sauf ld network : plus de support IPX et appletalk, new version netmap (émulation de n'importe quel driver réseau), modularisation stack TCP, et ajout de TCP fastpath (possibilité de swither) storage : améliorations perfs NFS et "cable control layer, iSCSI), améliorations ZFS, I/O throttling dans des jails maintenant possible + HA en iSCSI (actif-passif) ; module sendfile réécrit par Netflix Virtu : Xen dom0 (support domU) , bhyve (hyperviseur natif issus de Netapp) : peut booter du Linux et même Windows, Illumos ou Dragonfly via émulation UEFI ; HyperV guest très amélioré ; jails : ajout d'arg. CARP sur ip4/ip6.addr si vnet uniquement, top et ps émulé Nouveautés : fstyp, devctl, uefisign, sesutils (equiv sg3-utils), numactl, autofs (automontage d disque dans les VM BSD chez Gandi en cas d'ajout de volume), casperd (sandboxing capxicon), mprutils/mpsutils (utiliataires LSI equiv megacli) divers : support UEFI et GELI sur loader, support de Boot Environment dans le loader, groff remplacé par mandoc ; mêmes bases de locales que Linux ; maintenant linux64 ; ajout de Dragonfly Mail Agent (sendmail off) Kernel crash dump chiffrés package de la base Arrivée 27/07/2016 ## questions support multi-écran : en court # Du système au réseau, histoire d'un coming-out Pourquoi ? bankable datacenter L2 vlan firewall core (backbone, bgp) acess (collecte, CPE) monde network assez fermé => peu de doc, peu de partage de connaissance, beaucoup de matos proprio et os proprio évolutions parfois publiques plus de réseau humain (peering, opérateurs, aide DDOS, aller aux FRNOG) A venir automatisation : norme netconf => ansible, pyez, napalm SDN : pose questions de design L2less routeur opensource : DPDK, ou packet journey de Gandi , bird (un quagga like) switch open en cours de dev : OS open, chipset proprio (Broadcomm, Marvell, ....) JunOS ou pas => Cumulus (Debian modifiée), implem OpenSwitch à venir

Notes Suse Expert Day 2016 Paris

Olivier Duquesne aka DaffyDuke — 2016-02-03T14:04:00Z

rappel uber => moins de soustraitance shadow factu => shadow it "docker, vous n'y échapperaez pas" SLES 12 SP1 Rappel cathedrale et le basard - assurer stabilité et support6SP attendus + extended support = 13 ans find SLES 12 GA = 2016-06-27 presentation en mindmap maintenances systemd + wicked Ajouts : yast2-journal (journalctl de de systemd), SMT dans zypper now, SSO shibboleth teamd remplace bonding - SP migration changée pour Suse manger3 migration possible de 11SP3 à 12SP1 gestion des extensions (cloud etc ....) migration possible et rrollback si pb (btrfs & snapper) Note e, SP12SP1 : xend a été abandonné par la comminauté , pousse à migrer vers libvirt possibilité via guestfs de passer de xen à kvm OpenQA = clickodrome pour jenkins & co , exemple - valider syst de fichiers, - pacjages, - benchs => GUI sur état des test réalisé, échoué, autre .... JeOS = SLE pour virtu : 300 M (pas encore docker à 25 M) Docker / SUSE "facile de faire n'importe quoi" pb de registtry docker io => prthus : rechereche authenticifaction Canal module docker de Suse pour avoir les images docker (12SP1 en mars) comparaison avec pulse u rutiliser portus, bien faire le docker login avant sinon part vers docker io par défaut destination à préciser pendant le docker tag puis docker push virt-builder = gestion de cache d'image et personnalisation durant le download , à venir image jeos en Suse SP2 \_> ex modifier les password, format d'image disk, taille du disk, etc .... => faire du docker 2 libvirt Suse Manager 2016 Antoine Pierre Suses support RedHat, CentOS, SLES, provisionning VM, bare metal package management via channels et patchs \_> ajout de configuration en plus des patchs, gestion des CVE, openscap \_> en SM3 : ajout de gestion de configurations via SaltStack + souscriptions + monitoring (icinga intégré : deploiement auto des sondes en activant le monitoring depuis suse manager puis le push vers Nagios) Commandes via SALT? sans passer par OSAD Ex : gestion des LVM, vérifier des ports, firewall, etc ... salt-key -L = puppet cert list Besoin d'un démon sur le client => besoin d'accepter les minions depuis suse manager monitoring avec des test d'hdparm par exemple Ajout d'un "Remote command" execution de coimma des via le serveur saltmaster jeux d ecommandes peuvent etre bridées via spacewalk => sorit mi 2016 Bonne spratiques en cours de travail (script de migration suse manager 2.1 vers suse manager 3, ) CEPH "je vosu regarde droit dans les yeux, oui, vous pouvez mettre vos données là dedans" Attention, pas de VM prod encore, pas assez d'IO pour cela stockage froid essentiellement A venir bientôt : compression à chaud, dedup, cluster FS, " lopen source est farceur sur les noms, surtout ils prennent beaucoup de lsd" A OSD / disk storage node = serveur x86 algorithme crosh pour CEPH 3 monitor / CEPH => trosis reference fichier SES2 : iSCSI + objet SES3 : asynchrone?, CEPH FS, NFS => Pierre ; CEPH et réplication dans espace de travail Owncloud Blog OS David Byte Suse => 10g de preference, bonding sur 5 cates rx OpenStack Suse Cloud 6 IAAS )> PAAS )> CAAS (container) software defined ravio release update à partir de Suse CLoud 6 !!! HA syr EC Dept auto HA via OCF? Pacemaker HAWK2 admin pacemaker attention à ne pas subir les contraintes des etudes openstack permet catalogue de services rapprochement de Pivotal (cloundfoundry) nova : EC2 pour instancier des VM dont l'image vient de Glance noca-docker : EC2 pour instancier des images dockers dans un Glance (au format adapté) pivotal émarrées depuis nova Heat : orchestrateur OpenStack, c'est lui qu iorchestrera les container sur les les VM via kubernets ou swarns plugin magnum : baies kubernetes, baie rocketOS, .... et eat orchestre via nova => pas production ready crawbar = projet Dell initiallement, voir Fuel comme alternatove à crawbar

Notes présentation RedHat Satellite 6

Olivier Duquesne aka DaffyDuke — 2016-01-14T13:52:00Z

Notion de content view au lieu des canaux Utilisation de la GUI Katello => surtout des API et hammer (foreman) Foreman = GUI Puppet, GUI Ansible undef Puppet2 ? Notion de manifest satellite => souscription via candlepin Agent katello + agent puppet Capsule (=proxy) peut aussi faire tftp + provisionning Organisation / métier Renault Airbus 5000 serveurs sur 2 capsules (32 Go de RAM par satellite) Mise à jour de 6.1 vers 6.2 => mise à jour "streamline" à condition de suivre les guidlines (ex: Marcadona 6000 caisse sous Satellite) Canaux + git + fichiers => Satellite Notions de content view par dev/qa/prod => 1 capsule par env. Ex: une content view par classe, une composite contient n content view Démon policyd en plus (dashboard ?) Cloudforms pour le cashback et le monitoring IDM = freeipa, supporté dans RHEL en standard Satellite 6.1 = Katello GUI = Foreman 1 souscription smart unlimited / DC OK RedHat 5/6/7/SAP .... Notion de promotion de content view (rpm+conf puppet) Notion de canal figé en pulp sur release mineure possible, dans une content view CentOS est une version downstream de RedHat. 6/7 des salariés sont RedHat => RDO (OpenStack communautaire) CentOS est utilisé pour ça Plus d'erratas réguliers sauf pour ceux d'OpenStack Plus de support CentOS là où RedHat en faisait CentOS ne sera plus identique à RHEL. Orchestrateur RedHat => CMP

Notes présentation RedHat OpenShift

Olivier Duquesne aka DaffyDuke — 2016-01-14T13:50:00Z

OpenShift Origin Kubernates (Google) Docker Cloudforms => catalogue de service, chargeback, souscription à prévoir pour gérer cloud public ex : démarre une instance openstack pour le provi openshift Participation à l'Open Container Connecteur pour SAP HANA Service ESB Paramétrage pour persistence du container ELK inclus dans OpenShift Filebit par défaut Plus aggrégation de métriques Jenkins possible mais pas de base (ex un jenkins par projet) Docker image => container => pod => node <= registry policy par tag c'est kubernetes qui gère les expositions ex la BDD via TCP_3306 pour une appli de la registry interne, puis un autre pod si besoin juste ne faisant le lien vers le nom dui pod de la bdd (sous réserve qu'elle soit tagguée) haproxy en front pour faire du routage de nodes projet = namespace openshift (all in one dans origin) container build construit, DNS en wildcard géré par le bind interne sur la haproxy Versions d'évaluations possibles sur 30/60/90j Openshift dans une VM (KVM jusqu'à 40 container sur une VM de 8 Go de RAM) https://www.openshift.org/vm/ Cas clients La Banque Postale : kill ESX Amadeus amazon roadshow Exemple API oc login oc>oc delete all --all

Notes Susecon 2015 - Amsterdam

Olivier Duquesne aka DaffyDuke — 2015-11-02T13:55:00Z

- Au boulot / kernel, linux, virtualisation

Notes préparation RHCE

Olivier Duquesne aka DaffyDuke — 2015-10-30T11:21:00Z

Présentation par Frédéric Célié

Insérer ici les notes

Préparation avec Stanislas Zett

Première action du lab RHCE : yum install man kernel-docs procinfo
La conf DNS dans le fichier d'interface
systemctl restart NetworkManager
attention eth0 renommé en eno1 (p:pci , n:ethernet, 0:slot)
si /etc/default/grub pour revenir en eth0 si besoin ip addr list => nmcli notion de profil à l'interface => nmcli conn show (interface)
nmcli = persistent = smitty
Voir les interfaces vlan nmcli conn mod eno1 ipv4.dns 8.8.8.8 nmtui
=> même lacp, bridge & co
-p : pretty
route statiques via un fichier de routes appelées par la commande ip r systemd
/usr/lib/systemd/service : ajout des services puis jouer sur etat
rien dans rc et init.d
systemctl get-default beep : setterm -blength 0 etat = enabled/disabled/hide
systemctl status <service> pour voir les hide
delay sur cron pour random systemctl isolate graphical.target tips : mettre un <mount>.mount dans systemd systemctl --failed => list les process tombés systemctl list-unit-files
systemctl list-unit --type=target
systemd-cgtop Journaux
journalctl -p err
journalctl -f -p err <tail -f log>
journalctl -xm timedatctl (set-ntp 1)
chrony => NTPD
chronyc sources -v hostnamectl status
hostnamectl set-hostname <hostname> boot single HS via grub
systemctl isolate rescue.target => a revoir
grub : init=rescue.target : boot en mode single
chroot /sys/sysroot Boot order from vmlinuz grubline
rd.break
rescue.target
emergency.target
multi & others puis chroot
(besoin d'un remount / rw)
touch /.autorelabel

Notes Meetup Docker - chez Ecreall

Olivier Duquesne aka DaffyDuke — 2015-06-15T16:06:00Z

docker build -t hello puis docker run it hello /bin/bash docker exec -it <id> /bin/bash <= screen attach setup, puis install de packages par exemple puis sur cloisonné depuis l'hyperviseur : docker ps (équivalent) container = image, le / est rw mais c'est l'image qui est provisionné on peut en lancer plusieurs sans soucis mode démon : docker run it <dockerfile> (attention, commande doit garder stdin) (dockerfile < EOF from debian add memory /usr/local/bin # add pour prendre en local et pousser dans le dfile run date > titi.txt # execution dans un ficher interne # notion de cache apt-get update && install apt-get install apache2 # mapping de port expose 80 # binder l'apache sur le port 80 , besoin du docker -P pour démarrer ou docker -p 8000-80 pour mapping 8000 vers 80 # volumes volumes /data # pas besoin d'historiser, donc données ignorées # -v /coin/data:/data : monte le répertoire , volumes peut servir pour un pseudo NFS , exemple utilisation pour centralisation des logs /bin/bash EOF ) Contraintes : que Linux x86_64, à venir Microsoft start-stop-daemon ne peut pas fonctionner dans un container : exemple tomcat6 a patcher dans /etc/init.d pas de mapping user dans le dockerfile contrairemeznt à lxc docker tag <ancien nom> <tag> exemple registry.deliverous.net/ docker log pour s'autenthifier sur le repo docker images # listing des images sur le repos Mise en place de signature sur le push pour verifier, pas par defaut sur docker.io, mais OK sur rocket (CoreOS) Nov14 docker : un binaire en root , rocket : n binaire en userland Avantages : utilisation des capa pour mettre des quotas (-m 64m par exemple) Notion de cache du dockerfile : docker history <docker> Utilisations puppet, ansible, salt (donc plus de layer) docker push <image> : utilisation des layer sur la creation du container : envoi sur docker.io Pas de ménage chez docker.io mais blacklist possible chez docker.io "bien vu" de pousser chez docker.io pour heberger docker, exemple via un proxy, mais pas obligatoire exemple OVH Attention ne pas mettre apt-get update dans le layer car mise en cache et donc pas de mise à jour en cas d'install soft/vers # sinon docker build --nocache docker compatible SELinux grace RedHat FS supportés : brtfs, device-mapper WebHook entre Github et docker.io pour rebuilder l'image, exemple debian or debian gesty pas encore dispo (systemd par defaut) , run ne démarre pa sle package car runlevel S , or systemd pas compatible avec le runkevel attendau (notamment udev) Namespace et Cgroups as openvz Exemple clients : 3Suisses, Camaieu /etc/hosts non modifiable, ou alors dnsmask ou alors docker 1.5 d'il y a une semaine si on démarre un container dans un container, les variables ocmmencent par <nom container> ,exemple un container se connecte à un autre en decouvrant les param à chaud

KVM evaluation

Olivier Duquesne aka DaffyDuke — 2011-09-12T15:26:00Z

Virtualisation Matérielle

Tout d'abord KVM n'est utilisable que sur des processeurs implémentant un mode de virtualisation matérielle : - VT (Virtualization Technology) chez Intel - SVM (Secure Virtual Machine) chez AMD

Le principe de ce mode de fonctionnement est le suivant :

Par défaut, un processeur dispose de 4 niveaux d'exécution appelés « rings ».

Sur une archi x86 32 bits, le système d'exploitation fonctionne sur le ring 0 et dispose du plus haut niveau de contrôle à l'inverse des applications qui tournent sur le ring 3.

Les couches de niveau supérieures ne peuvent pas modifier le comportement des couches inférieures, seul l'inverse est vrai. (Un OS arrête une appli, pas l'inverse)

Les rings 1 et 2 sont des niveaux intermédiaires, peu utilisé et donc supprimé sur les archis x86-64.

Le passage en mode privilégié est standard sur des archis x86, ce sont nos chers syscalls.

Exemple :

On fait un « open » en userland, une interruption (int 0x80 sous archi x86 pour ne pas la citer) est envoyée au kernel qui passe dans la fonction « trampoline » codée en assembleur (fichier syscalls.S si je ne m'abuse) et qui permet de switcher le processeur en mode privilégié, le fameux ring 0.

A partir de là on est en kernel mode, le processeur est au ring 0 et tout est possible.

Revenons à nos moutons :

Lorsque l'on virtualise, on utilise un OS privilégié : l'hyperviseur. Il contrôle les hôtes et les ressources physiques et utilise le ring 0.

L'hyperviseur gère les guests qui doivent donc, pour respecter la hiérarchie de contrôle, utiliser les rings 1 ou 2.

Le problème est qu'un OS est conçu pour ne s'exécuter que sur le ring 0, il vérifie qu'il réside au bon endroit mémoire dédié aux OS et certaines instructions ne s'exécutent que si elles viennent du ring 0 ou y vont. (et heureusement…)

Pour pallier à ce problème, on utilise donc la virtualisation.

La paravirtualisation (XEN) consiste à modifier les OS invités pour permettre un mode d'exécution autre que le ring 0.

Lorsque l'on ne peut pas modifier le code de l'OS (…), on procède à des translations binaires (VMware, QEMU) pour faire croire à l'OS qu'il occupe un emplacement mémoire valide ainsi que le niveau d'exécution processeur ring 0. Evidemment, ce dernier mode est plus gourmand en ressource.

Les technologies de virtualisations matérielles consistent à créer un nouveau mode d'exécution (VMX chez Intel). On a donc un niveau racine < ring 0, et un niveau normal correspondant aux rings 0-3 décrits précédemment. L'hyperviseur s'exécute en mode racine et les hôtes en ring 0. Pour ceux qui s'imaginent déjà que nous nous sommes complètement affranchis de la translation binaire, je suis désolé mais ce comportement est encore nécessaire pour certaines fonctions.

Lorsque l'on se penche sur les sources de KVM, les développeurs mettent en avant un code concis, clair et permettant de profiter des améliorations du kernel 2.6 sans effets de bords possible. C'est précisément parce que les technologies VT et SVM existent que cela est possible.

Maintenant que les guests OS disposent d'un espace d'exécution dédié ainsi que d'un niveau d'exécution qui ne les perturbe pas trop, il va falloir partager un peu les ressources, l'hyperviseur est généralement dédié à cela.

Naturellement un guest OS se croit seul au monde, et l'hyperviseur se doit de faire du context switching d'OS pour fournir des « time slice » en fonction des besoins de chacun. Pour rendre possible tout cela, il faut stocker une image du système, sauvegarder les registres, les caches etc… et remettre tout ce petit monde en activité régulièrement.

Les technologies VT et SVM disposent d'un jeu d'instructions dédiées à ces taches (VM Exit, VM Launch, VM Resume…), d'un jeu de signaux spécialisés dans l'évènementiel (interruptions hardware, Idle Time) et chaque hôte se voit allouer un segment mémoire de quelques Ko de son espace d'adressage pour stocker les données d'état. Cet espace est évidemment lu avant chaque mise en activité et écrit à chaque context switch d'OS.

Exemple :

Le processeur utilisé alors par un guest OS vaque à ses occupations, reçoit un signal connu et référencé dans son handler (table de 32 bits), il lance VM Exit et passe la main à l'hyperviseur. Ce dernier lance son processus de sauvegarde d'état puis effectue un éventuel context switch par le biais de VM Resume puis VM Launch.

L'hyperviseur dispose ainsi d'une granularité de contrôle importante et c'est très peu consommateur en ressource.

Fonctionnement de KVM

Nous disions donc que KVM nécessite le support des fonctionnalités processeurs de virtualisation matérielle.

Le fonctionnement de KVM est basé sur un hyperviseur. Par abus de langage, le terme d'hyperviseur est assimilé à l'OS privilégié qui gère les guests OS, c'est inexact. Pour être précis, l'OS privilégié exécute des tâches critiques sur demande de l'hyperviseur qui est une entité fonctionnelle dans le kernel. Cette entité étant basée sur diverses technologies matérielles et algorithmes.

Dans le modèle KVM, l'hyperviseur est donc basé sur : - Les technologies de virtualisations matérielles - Le scheduler kernel - La gestion de la mémoire du kernel - Un développement propre au projet permettant, entre autres, d'organiser et ordonnancer tout cela.

L'hyperviseur gère le scheduling des taches au sens large du terme, la mémoire et délègue les IO à un hôte privilégié.

Par défaut, un OS Linux dispose de 2 modes de fonctionnement : User Mode et Kernel Mode.

KVM ajoute un troisième mode appelé Guest Mode qui dispose de ses propres User Mode et Kernel Mode.

Les taches sont décomposées de la façon suivante : - Les OS invités sont exécutés en Guest Mode, on y traite toutes les taches hormis les IO. - En Kernel Mode on ordonnance les OS invités et les requêtes d'IO de ces derniers. - En User Mode on exécute les requêtes d'IO des OS invités. (c'est là ou cela devient amusant…)

On remarquera qu'à aucun moment, dans le modèle décrit, il n'est nécessaire de créer un scheduler de taches, un système de gestion de mémoire, un patch pour des drivers hardware. C'est précisément ici que se trouve la valeur ajoutée de KVM. Il est natif au code du kernel Linux, ne nécessite pas de maintenance pour les drivers hardware et bénéficie de toutes les améliorations kernel. (Pour rappel, à partir des kernels 2.6, le scheduler de tache est en O(1) et sera encore amélioré, il serait dommage de ne pas en profiter….)

Utilisation de KVM et résultats de tests

Pour revenir à des choses un peu basique, KVM est implémenté à partir des versions de kernel 2.6.20 et se décompose en : - Un module kernel « kvm », implémentant l'API globale de scheduling, de gestion de mémoire, le Guest Mode et l' « intelligence » de l'outil - Un module « kvm-intel » ou « kvm-amd » comprenant les traitements et instructions propres au processeur utilisé. - Un device driver /dev/kvm (le minor number est alloué dynamiquement, pas vraiment pratique pour industrialiser…) permettant de contrôler KVM et les guests OS.

Ensuite nous utilisons l'outil userland QEMU, légèrement modifié pour prendre en compte /dev/kvm ainsi que le module d'accélération matériel kqemu. QEMU s'occupe de gérer l'émulation hardware, on a parlé d'IO tout à l'heure, c'est par ici que cela se passe.

QEMU est utilisé pour gérer les OS invités à savoir : - le démarrage - l'arrêt - le monitoring - les espaces disques (le guest OS est-il sur un ensemble de partitions LVM2 ? dans un fichier monté en loopback ? sur un CDROM ? dans un fichier ISO ?) - les interfaces réseaux (natif, VLAN …) - l'accès au guest OS via VNC entre autres - l'activation / désactivation des options de boot comme l'ACPI ou l'USB - le copy-on-write des images disques - etc etc…

Son utilisation n'est pas du tout conviviale et l'industrialisation de l'outil ne révèlerait pas straightforward.

On boot sur un kernel 2.6.21, on charge les modules kvm, kvm-intel (on aura au préalable activé le VT dans le BIOS), kqemu (module d'accélération matérielle).

On crée les devices /dev/kvm et /dev/kqemu avec les minor qui vont bien.

On démarre un Guest OS par le biais de qemu :

qemu -boot c -hda /dev/mapper/vg—ld0-pouet_kvm -hdb /dev/mapper/vg—ld0-pouet_work -k fr -vnc 0:0 -daemonize -m 1024 -net nic -kernel-kqemu

A partir de ce moment, QEMU vérifie que nous avons monté une shm d'une taille suffisante pour le guest OS (1024 dans notre exemple), ensuite il mmap() la mémoire physique de l'hôte invité puis appelle le module kernel kvm (par le biais /dev/kvm) pour qu'il lance le Guest Mode.

Un Guest OS est naît.

Si l'on se penche maintenant sur le cheminement suivit par les processus d'IO, cela se déroule comme suit :

Un OS invité envoi une interruption d'IO. (Guest/User Mode puis Guest/Kernel Mode) L'hyperviseur (j'ai bien dit hyperviseur…) reçoit la requête et la transfert à l'OS privilégié (shm quand tu nous tiens…). En reprenant notre exemple, l'OS privilégié sera l'OS depuis lequel nous avons lancé la commande « qemu » et crée le guest OS.

Le scheduler de l'hyperviseur procède à un context switch d'OS pour donner la main à l'OS privilégié. On arrive ici en User Mode puisque, aux yeux de l'OS privilégié, c'est le processus userland QEMU qui a demandé la requête d'IO.

On appelle le gestionnaire d'interruption de l'hôte privilégié, qui envoi la requête au scheduler d'IO. (Kernel Mode) L'hôte privilégié procède à un context switch classique. (Kernel Mode) La requête d'IO est effectuée. (Kernel Mode) Ici c'est une requête d'IO classique. Pour résumer : Syscall -> VFS -> récupération de l'inode (fonction nameilookup dans namei.c si mes souvenirs sont corrects) -> switch sur le FS qui va bien -> remplissage d'une structure bioread après avoir récupérer le dinode (j'ai bien dit dinode), le driver hardware fait son boulot en flushant le buffer et on repart en sens inverse.

Un signal de fin d'IO est envoyé à l'hôte privilégié, on revient en User Mode pour repartir de suite en Kernel Mode, puis l'hyperviseur procède à un context switch d'OS pour revenir au guest OS initiateur de la demande d'IO. L'hyperviseur relance le guest OS. (Vous vous souvenez, VM Resume tout ça…)

L'avantage, lorsque l'on utilise KVM est qu'aux yeux d'un hôte privilégié, les guests OS sont des processus classiques. Les outils d'administrations standard fonctionnent donc sans problème (ps », « kill », « top »).

Les tests comparatifs ont été réalisés entre 1 OS privilégié et 1 guest OS : G5 doté d'un CPU 3.00GHz, 1 Go RAM, partitions LVM2

(ces résultats sont une moyenne de 3 benchs).

Tests IO :

iozone -s 1k -r 1k -t 200 -i0 -i1 -o OS privilégié / OS invité Ecriture 20 Ré-écriture 100 Lecture 12 Re Lecture 13

Tests CPU :

nbench

Je ne mets pas les résultats de chaque test ici, ce n'est pas pertinent dans la mesure ou la seule chose à retenir est que nous perdons, dans le pire des cas 3% de CPU entre l'OS privilégié est le Guest OS.

Les résultats des tests CPU et IO sont rassurants puisqu'ils viennent confirmer le mode de fonctionnement décrit précédemment.

En revanche, les résultats des tests d'IO sont très en dessous de notre seuil de tolérance.

Conclusion

Le concept KVM est sympa et très prometteur.

La majeure partie des points négatifs vient de QEMU, les IO sont mauvaises, l'administration des hôtes n'est pas limpide, pas de support 64 bits pour le moment, tous les hardwares ne sont pas supportés (disk et réseau pour ne citer qu'eux). Il n'est pas simple d'implémenter une archi Front/Middle/Back avec les VLANS qui vont bien.

Dans le cadre d'une industrialisation il faudrait créer un nouveau processus de génération de guest OS, un wrapper d'administration facilement utilisable ainsi qu'un outil de monitoring propre pour la prod.

Bref, avis défavorable en ce qui me concerne mais il faut garder un œil dessus car s'ils se mettent à faire un peu d'IO et qu'ils codent un outil d'admin/monitoring convivial cela peut être vraiment sympa.