Video Control, Optimlize,Innovate

Nils Brauckman open spource the way to innovate openstack success story agile, complet, sous control cost 2 marker distibuted storageceph May the open source be with you Cloud Foundry, docker => SAP, IBM On premise, PAAS, Cloud public Annonce de collaboration SAP à Hadoop, OpenStack, pour Cloud Foundry Chisuki Misagawa Fujitsu Migration de proprpio habituellement à open source pour innovation rapide : opensource is the answer to innovation IT Fujitsu migre dans OpenStac hat's true

Michael Jura : contributeur CEPH (manque de punch, ne regarde pas l'audition) opensource, distributed, redondance, CEPH=rados cluster object access like S3, block et distrivué => ceph architecture openstack.org/ cephfs possible via fuse utilisation de librados pour accéder en API faon S3 en php, ruby, Openstack : rackspace+nasa en 2010 SuseCloud=OpenStack+Crowbar => IAAS private Cloud Support OpenStack

• Cinder (since Esse)
• Nova (since Havana)
• Swift (since Icehouse) => remplace swift dans suse cloud
• Glance (since Diablo) RADOS gw apache2 + FastCGI devenu CivetWeb webserver Glance & CEPH : avec driver RDB Cinder : plusieurs volumes dans RADOS, boot volume depuis images pour éviter la volatilité du boot sur images, attachement de volume CEPH Nova : RDB configure libvrt via QEMU => activation de cache RDB possible Possibilité de mixer dySDD pool dans un pool CEPH, un pool HDD dans un autre pool => différents jeus de stockage C1, C2, etc .... en cours de dev : iSCSI RDB Gateway dans nova : iscsi target in userland, RDB dans le kernel Idéal pour VMWare ou Hyper-V => multipath supporté avec plusieurs gateway demo depuis une opensuse et un crowbar : ceph apparaît dans les barlamps Configurer le backend depuis GLANCE par exemple depuis crowbar Puis dans Horizon, provisionning d'une VM puis allocation d'un disque depuis CEPH

Flavio Castelli : mainteneur du conteneur sles12 officiel (marrant l apopup mises à jour) chiffres : 400M+ downl, 75000+apps docker rappel docker : stardisation d'une application packagée idéal pour du Paas rappel d'une archi standard docker, notion de docker rbuild .... puis register de lu container en registry (public par défaut) On premise rehistry mais pas encore parfait, pb d'audit, authentifctaion, travail collaboratif Portus = registry , docker tag "test" registry-insecure Portus se branche sur un AD, possibilité d'avoir des équipes de développeurs => une équipe dans un namespace http://port.us.org https://github.com/SUSE/Portus

Voir wiki microfocus suse manager Arrêt spacewalk zypper patch 2x, upgrade du schema, refresh récupération d'un ptf, mgr-sync refresh spacewalk-sql --select-mode file/sql or import de la requête à la main spacewalk-manager-channel-lifecycle utilisation des activation-keys preco : un canal suse manager avec des packages manuellement ajoutés mgr-create-bootstrap-repo => bootstrap script (en cron ?) troubleshooting : (installer supportconfig avant) : spacewalk-debug avec un debug=5 dans /etc/sysconfig/rhn.conf export URLGRABBER_DEBUG=DEBUG ; repo-sync .... tips : osa-dispather.debug=5 / taskomatic.maxmemory=4096 Forward registration to SCC/NCC : server.susemanager.forward_registration=0 Attention au NCCredential OSAD en cas de clone Objectif : en 1 mois, amotion identique à Decathlon Reco : un canal comm pplication des patchs, testés, promus, ... => bien décrire le scénario de tests Process décrit de pro un et un canal update par environnement de tests => notion de security-ASAP-channel merge command python, client.channel.software.mergePackages ..... Advanced Patch Lifecycle Management with

Andreas Jaeger Thomas Gottlicher => construction de master Suse pb : secu, compliance, requirements create systems (store state) + comparaisons, export vers outils d'install, api pour outils custom configuration discovery : pacakges, repo + conf system validation : os, packages, conf => validate service migration : export conf d'un DC, build vers Amazon création d'une base centralisée d'admin (ssh depuis cet admin) offline management ce ne fait pas de deploiement de conf ni de packages (pas yast) utilise puppet, ansible etc .... + plugin Suse manager en cours + AIDE (security tool) http://github.com/SUSE/machinery supporte RHEL5 et 6, docker, systemZ et PowerLE présence de workflow

Conference fun, distribution de chocolats à la lettre A Architecture : AMD64/Intel64, IBM Power, IBM Z, ArmArch64 B BTRFS : full system rollback with snapper & service pack migration C Compliance Certification (DISA STIG [hardening guide pour la défense], FIPS 140-2 (openssl, strongswan IPSec, crypto kernel api), IPv6 recertification D Docker : enterprise ready, sle2docker, zypper-docker, portus (registry locale) E Extensions : Enterprise Live Pacthing (), High Availability Extension, Geo Clusters, Real Time Extension, High Availability, Virtual Machine Driver Pack (windows en guest par exemple), Workstation Extension (desktop à part entière : Evolution, Libreoffice, ...), Long Term Service Pack Extension F Filesystems (schema BTRFS du cours) BTRFS pour OS, XFS pour Data sans snapshot, sinon BTRFS (si reiserfs, ext, alors conversion sous Btrfs) : perf DB mieux en XFS G GNOME3 : en classic pour desktop, KDE dispo via Workstation Extension (à vérifier) H High Availabilty : SAP/Oracle => OCFS2, DRBD data, Node recovery avec RearR, GUI pour toutes les confs possibles de stockage, hyperviseur, loadbalancing IPv4/IPv6 - Wizards pour migration de 11SP4 vers 12 (entres autres MariaDB), authent sur geoclusters, nouvelle version de HAWK H HPC : dans le top500 depuis 1992 : Lustre (high performance), CEPH (sécurisation sur plus de noeuds) sur 8192 cores I Interoperability : majorité des hyperviseurs, IPv6, NFSv4+ (autres Unix), Samba 4, authentification Windows SSSD J Just Enough Operating System : subset SLES pour cloud en images minimales => idéal docker K Kernel Live Patching PTFS sous forme de Live Patches L Lifecycle : 13 ans, 10 angs general + SP3 + LTSS (3 ans etendus) SLES 12 Q4-2014 en GA, SPI en 2015, SP2 fin 2016, SLES11 SP4 en 2015 M Modules : modules SLES étendu comme Web (RUBY, PHP), supportés : Legacy (sendmail, old java), certification (=frozen pour FIPS), Toolchain (gcc), systm management : machinery, cfengine), public cloud (amazon), container (docker & alls) N Network, IPv6, installation en pure IPv6 possible ou juste compatible O Others : Suse Manager pour les RPM et manage autres OS, SUSE OpenStack Cloud gère SUSE et autres stacks, SUSE Enterprise Storage : CEPH pour "tous" O Open Source (marketting) P Package Hub : collection de package communautaires pour SLES (vient de OpenBuild service par la communauté) et approuvé par SUSE) (un peu comme les modules mais avec une durée de support plus courte) Q Quality, OpenQA : http://en.opensuse.org/openSUSE:OpenQA intégration continue installations variées et tests => job avec entrées en json + screenshot/png et sorties en log ou screenshot/video R S Salt : conf management framework en mode distribué, Suse Manager 3 utilise SaltStack, sera ajouté en SLES11 et 12 T Teaming (nouvelle versoon de bonding) aggregation en userland avec teamd : LB, active backup, DB-Interface U Unix to Linux interoperability as a principle (not an addon) V Virtualization : guest, dispo en public cloud, contient plusieurs hyperviseurs (Docker, KVM, Xen)et donc private cloud avec openstack cloud W Wicked network management layer pour simplifier les conf de plus en plus complexes, independant d'archi, faible mprunte mémoire (bash), ajout récents de opevpn, open vswitch bridge, teamd X Xen, KVM, Containers : Xen 4.x, KVM qemu 2.x, libvirt & livirt-lxc (Suse 12 en 64 bits uniquement mais émule des applis 32 bits) Y Yast : solution intégrée de toute conf le seul sous Linux, écrit en ruby, possibilité d'écrire ses propres modules (maintenu par la communauté) (exemple le module docker a été écrit en 1 jour, facile en YCP) Z Zero Downtime : Live patching, System Rollback, HighAvailability, Geo Cluster, RAS

Stephen Zarkos Microsoft Long Lin Microsoft Christin Kinan Suse 22 regions 25% machine sous linux VPN pour On premise 32 CPU, 500 G RAM = large VM Azure file service (SMB 2.1 ou 3.0) => encryption, preview portal.azure.com (quota, get, ...) azurectl sur http://github.com/SUSE/azurectl azurectl --storage : créer le bucket puis montage en SMB (cifs) pass = chiffré dans le -o du mount Linux VM Extensions : injection des extensions sur la VM active vers un agent(exemple d'extensions : chef, docker)

• exemple : automation de configuration
• VMAccess : reset SSH keys sur recovery ou setup
• OS Patching : update & cron update Azure diagnostis, DSC (powershell pour configurer du Linux) Disk encryption à venir Un fichier de conf pour télécharger puis exécuter le script téléchargé (exemple présenté installation apache) Azure Ressource Manager (ARM) : role base access pour une application (équivalent d'un security group amazon et designer => injection d'un json pour recréer l'infra, LB, fw, ...) avec gestion des dépendances (je mets mon appli quand j'ai ma BDD) Azure HighPerformance Computing Infiniband network, RDMA driver sous Hyper-V (qu ia une carte mellanox connectX3), utilisation de Intel MPI (OpenMPI en cours de dev), Direct Access Application Layer sur le guest Linux => appelle la routine MPI Intel avec LS-DYNA par exemple)

Thorsten Kukuk (voir cahier)

Klaus Kampf : product owner Suse Manager en cours de dev inventaire de souscriptions topologie des besoins Scalabilité / disponibilité : 40000 hotes enregistrés = plus gros déploiement (docker par exemple) => SLES HA Configuration management addons : SLES12SP1, monitoring INCINGA, 1H2016 fin de support Oracle any input, à travers le temps SM2.1 : schedule kernel vendredi prochain à 4h SM3 : vérifie que le prochain vendredi à 4h tu as la dernière version de kernel pb des puppet, chef, ... un agent se connect au serveur, il est intrusif, moins de fonctionnalités, pb de langage pb de salabilité Infrastructure as a code, code augmente en puppet => spaghetti code saltstack = choix de suse

• clients autonomes
• utilisation de la base de suse manager
• 13 Mb d'empreinte mémoire (contre 18 puppet)
• bcp plus rapide (10 sec salt contre 10 min puppet)
• modules pour tout Control Flow : Salt Master (base de Suse Manager) => message bus state (=manifest) => minion ( = node) Master a les données (pillars) a les clés SSH, interroge le client (grains = facts) => GUI pour patch, conf & packages focus sur les écarts uniquement possibilité d'appliquer une conf sur un groupe spacewalk => penser à faire un fact modification faite tout de suite quand modif sur le master, le minion la prend tout de suite, versionning en base de données (pas dans un git tiers) A vérifier la possibilité de gérer autre chose que de la SUSE On peut garder OSAD mais dans le futur, le client SALT fera le job notifications au master des changements Beta pour la semaine prochaine Roadmap : proxy salt, salt-ssh (agentless), salt-modules-puppet ou chef pour agir sur puppet .... en off : Puppet enlevé des repos SUSE12

Markus Gurtier SAP architect (bascily 28x) Stefan Scheinder SAP solution architect stch@amazon.de réplication habituellement sur un seul datacenter réplication de stockage de DC à DC bascule en cas de DR est manuelle : "sr_takeover" => 30 min dans le meilleur des cas system memory & memory preload (repli de RAM) utilisation du studio pour agir sur la réplication bonne pratique : Installation SAP Avant la mise sous cluster (Suse Cluster = Pacemaker) Installation de SAPHanaSR et suivre le wizard HAWK => scale up Replication dans un VPC entre deux AZ Attention au system group et AIM pour avoir les deux dans les 2 AZ Pacemaker EC2 API pour le fencing => pas d'autoscalling pour que SAP ferme proprement ses applis et ne gère pas bien le LB AWS et ne gère pas non plus le downscale Pas d'utilisation d'Elastic IP, mais utilisation d'un aws-vpc-move-ip

Ryan Trauntvein devops @ novacoast.com Dan Elder sales Devops ne règle pas les tensions en équipe chaque container est indépendant, moins d'empreinte mémoire liée au guest OS Securité : pas d'accès SSH, stateless, rapid, audit trail, moins de barrière système, dev secu Utilisation de apparmor/SELinux dans le container Surtout pour des applis web, microservices, idéal pour tester la dev avan t passage en production Ne pas le faire : grosse monolithic applis, appli legacy à refaire, Quand : test, déploiement d'applis, nouveaux projets Quand ne pas le faire : si pas de Linux, projets déjà lancés Cas d'école : 130 applis : 30 minutes pour refaire tous les container et faire pointer le LB vers les nouveaux Cas d'école : grosse IT middleware sans outils centralisés, ont subi une grosse attaque => setup.sh d'un JBoss depuis un container Cas d'école : création de micro services http://12factor.net

• codebase : versionning !
• dependances : déclarer les dépendances entre containers
• config : garder la config de l'environnement hors container
• backing services : tout prendre à chaud
• build, release, run : bien séparer les construction avant mise en production
• processes : stateless
• port binding : exosition de service
• concurrency : DOIT être scalable
• dispo : robuste via microservices
• faire dev et prod aussi proche que possible
• logs : les récupérer dans un syslog
• admin : une tache par process https://github.com/novacoast/opensuse-docker-apache/ et SDLC Lifecycle development https://codeship.com

https://hub.docker.com/r/novacoast/opensuse-apache/

Thomas Krenn : Florian Hettenbach FS : Linux, Windows, Enterprise (NAS), ZFS, entrée de gamme Sylogy/QNAP, object storage avec Suse : CEPH spécialisée (Netapp/EMC) => Standardisé sur n'importe quel disque avec des HBA low cost 64 G de RAM, 8 Tb HDD, 1 To SSD, réseau 10 G base T, CEP branché en S3 Swift, RADOS, ou iSCSI SLES12+Mon-D (CEPH)+SES2+monitoring Calamari : https://github.com/ceph/calamari comparaison de chiffres => chercher indico cern ceph pdf présente d'un /graphite/dashboard dans un Suse Storage CEPH Architectre : prendre des HBAs , ne pas prendre de RAID controller + Jumbo Frame + au moins 64 Gb RAM(Software defined) Ne pas négliger le tuning eéseau et les logs Attention aux plannings

Mainframe, 7 avril 64 données critique, 92 du top 100 banques, => SLES supporte long support IBM z13 (BC = business class = small class), (EC = Enterprise class) 15 ans de Linux sur zSystem (Suse était la première) IBM LinuxOne Systems : Emperor & Rockhpper (entrée de gamme) z13 overview : z2964, 85 partitions (LPAR) IFL : Integrated Facility for Linux : http://www-03.ibm.com/systems/z/os/linux/solutions/ifl.html =>KVM et autres pas de nouveaux clients depuis des années, certain ont compris et utilisent, mais peu franchissent le pas compatibilité : http://www-03.ibm.com/systems/z/os/linux/resources/testedplatforms.html Sicoob économise des millions de dollars http://www.ibmsystemsmag.com/mainframe/casestudies/banking-finance/Sicoob-mainframe-virtualization/ 500 zVM, passé de 310 serveurs physiques à 36 ! Mongo, MariaDB, DB2, .... workload real time analitycs sur zSystem à voir sur demo Linuxcon (18 min) moins de problème de charge CPU sur zSystem que sur x86 sur la gestion des priorités par exemple 1080 produits supportés https://github.com/linux-on-ibm-z/docs/wiki/ Virtualization LPAR, IFL, Virt Managmt, Linux Guest 30 T de RAM supportés en KVM pas de sens de faire du docker ici au vu des besoins existants des systèmes Z voir le projet KVM for IBMz Systems ... HPV = hyperviseur pas opensource mais supportés par KVM OpenStack : supporté par nova en arcg s3960x à partir de la version Kilo Limits : reco 10:1 CPU, en réalité, on n'a pas tout testé, 8 To de RAM Difficultés : on trouve des limites théoriques, mais trouver qui a réellement essayé est difficile (vor les docs Xen à ce sujet) Oracle ne supporte pas KVM ou VMWare ou autre virtualisation SAP supporte KVM/zVM sur Suse Shopz est le site de référence pour les produits puis souscription pour Fix Central (abonnement) Lifecycle ; KVM 1.10 2 ans de vie, 4 ans étendus

Jeff Lindholm SUSE Challenge : loi de murphy ..... Key features : Pacemaker : tagguer les objets SLES + HA Extension + VMWare fencing plugins pour un peu tout apache, sap, websphere, nfs, .....) Implémentation d'un HA entre vSphere vmtools intégré sles12

• open-vm-tools : souris
• vmware-ballon : memory driver
• vmw_vmci : guest & hyperv
• vmxnet3 : nic
• vmw_pvscsi : disk perf
• vmwgfx : kernel 3D Tous sont supportés par le support L3 VMWare Voir la doc SAP : http://scn.sap.com/docs/DOC-25453 HA Stack pour SAP : bonding + multipath + md-raid / ext3+LVM / pacemaker/OpenAIS Utilisation des drivers fournis par Suse SLE HAE SBD pour le fencing unicast heartbeat pour deux noeuds désactiver le "simultaneour write protection" sur VMFS Activer la présentation by-id idsk : disk.enableuuid="true" dans le vmx config ajouter le modprobe softdog dans le /etc/init.d/boot.local http://kb.vmware.com/kb/1034165 La conf doit rester le plus simple possible + SBD + prévoir tous les scenarios de casse Surtout ne pas partir avec un cluster sans stonith, sans tests, SBD timings inférieur à ceux du SAN Faire un zero thick provisionned eager sur ajout de disk kb 1033570 ajouter un sharing "sharing = "multi-writer" vérifier /etc/sysconfig.lvm pour vérifier les volumes au boot et ne pas monter le SAN => Utiliser OCFS2 autant que possible Demo, cluster status pacemaker : http://clu:8080/mainstatus utilisation du clone de ressource pour avoir une homogeneité de conf