понеділок, 7 грудня 2015 р.

Docker та екосистема контейнерів

Деякі цитати з електронної книги "Новий стек", що є першою книгою серії "Docker та екосистема контейнерів". Фактично, ця книга є добіркою популярних статей про Linux-контейнери та Docker -- технологію роботи з ними. Оригінал книги можна завантажити за наступним посиланням: The New Stack: The Docker and Container Ecosystem eBook Series.

Хмарні технології запропонували нове сприйняття обчислювальної інфраструктури як гнучкого та здатного до адаптації ресурсу, що відповідає потребам бізнесу в 21 столітті. Інформаційні технології, базовані на хмарах, вимагають фундаментальної зміни сприйняття інфраструктурних компонентів, які раніше були громіздкими, дорогими, спеціалізованими, які потрібно було створювати "вручну", та було дуже складно змінювати.
Docker починав подібно до хмар, створюючи враження зручнішої технології для формування пакунків (packaging) та розміщення (deployment) застосувань. Насправді, контейнери торують шлях до ще більших змін в усвідомленні ніж хмари.
В той час як хмарні технології змінили спосіб, в який ми керуємо "машинами", вони не змінили базові об'єкти керування. З іншого боку, контейнери докорінно руйнують нашу прив'язаність до традиційних серверів та операційних систем. Вони переносять наголос на застосування та компоненти застосувань. Можна сказати, що контейнери у поєднанні з моделлю програм у вигляді мікросервісів формують об'єктно-орієнтоване, компонентне бачення архітектури застосування.

Контейнери мають довгу історію. Docker -- це лише нова ітерація, яка спрощує і робить зручнішим розробку, розміщення та керування застосуваннями. Контейнери -- це процеси, частини системи, які внаслідок мутацій обирають різні форми.
Технологи Docker часто визначають Docker як спосіб доставки, побудови, запуску та розміщення застосувань. Він часто є платформою для розподілених застосувань. Його застосування можливе там, де використовується Linux, тобто майже всюди; він також може працювати під Windows. Docker не пов'язаний з будь-якою операційною системою.

Контейнери цілком реалістично можна вважати етапом на розвитку технології, продиктованим сучасним ринком. Безсерверні архітектури які здобувають прихильність як спосіб абстрагуватися від складності розподілених систем. Можливим наступним етапом буде використання юні-ядер, які завойовують симпатії внаслідок ще більшої легкості ніж контейнери.

Різні компанії пропонують свої шляхи використання контейнерів. Зокрема, платформа Amazon Web Services інтегрується з контейнерами за допомогою сервісу EC2 Container Srevice. До подібних підходів належать IBM Containers on Bluemix, CoreOS Enterprise Registry, JFrog's Artifactory, Google Container Registry, Quay.io та безперечно Docker Trusted Registry.

Docker та контейнери забезпечують переносиміть, швидкість ефективне конфігурування та концентрацію напрацювань подібно до Git-концентратору (GitHub).
Переносимість забезпечується особливостями пакування контейнерів, завдяки яким контейнер, який виконується в публічній чи приватній хмарі, або безпосередньо на апаратній платформі (bare metal), є повністю аналогічним до того контейнера, яким його створив розробник на своєму лептопі.
За швидкістю Docker-контейнери, які здатні завантажуватися за секунду, значно переважають віртуальні машини, яким для завантаження потрібні десятки секунд або навіть хвилини.

Створена в червні 2015 року організація Open Container Initiative (OCI) надає відкриту специфікацію і вимоги щодо середовища їх використання.

Минулої осені CoreOS оголосило свою специфікацію rkt для своєї системи використання контейнерів Rocket. Минулої весни компанія повідомила про свій власний проект з відкритим кодом App Container (appc), базований на технології rkt.
CoreOS має фінансування від Google Ventures. Технологія CoreOS глибоко інтегрується з Kubernetes, платформою з відкритим кодом для керування контейнерами від Google. У свою чергу Google сфокусувалася на роботі нещодавно оголошеної фундації  Cloud Native Computing Foundation, яка концентрується на керуванні контейнерами.

Безсумнівно, Docker змагається і з CoreOS, і з Google. При цьому всі три системи також кооперуються, що відтворює нюанси цього світу розробки застосувань та керування масштабними системами, в якому немає єдиного універсального рішення.

В гібридному хмарному середовищі контейнери можуть виконуватися в Docker, керуватися Kubernetes або Mesos, покладатися на Consul або etcd для віднайдення сервісів, тощо; але ще більш важливо те, що в кожній хмарі можуть використовуватися різні конфігурації інструментарію та інфраструктурних компонентів. Це означає, що системні дані можуть знаходитися на ресурсах власника, в той час як тимчасові дані зберігаються в хмарі Amazon Web Services, або доступні через Open Stack для негайної обробки.

Стек застосувань, запропонований компанією Rally, базується на апаратних засобах та драйверах. Інфраструктура віртуального апаратного забезпечення створюється гіпервізором, який забезпечує систему з розподілу реальних апаратних ресурсів.Зверху гіпервізора знаходяться операційні системи на кшталт CentOS. Поверх останніх розташовано середовище Docker. На найвищому рівні знаходяться застосування.

Додаткові джерела


  • Linux Containers and the Future Cloud. By Rami Rosen
  • Docker
  • Open Container Initiative
  • субота, 28 листопада 2015 р.

    OpenVSwitch в системі CentOS7: базові налаштування

    Вступ

    OpenVSwitch (OVS) -- це програмне забезпечення з відкритим кодом, яке призначене для створення у системах з віртуалізацією компонента, еквівалентного за функціональністю керованому Ethernet-комутатору. Наразі OVS використовується здебільшого в системах Linux з усіма найпоширенішими гіпервізорами для віртуалізації -- KVM, VirtualBox, Xen.
    OVS типово встановлюється на фізичному сервері-носії, що використовується для запуску віртуальних машин, та є альтернативою для використання мостів Linux (Linux bridges), маючи значно ширшу функціональність. OVS також є вдалою альтернативою комерційним продуктам на зразок віртуального комутатора Cisco Nexus 1000V.

    В даній статті розглядаються базові дії зі встановлення та налаштування OVS в системі CentOS7, що є вільно поширюваним аналогом комерційної системи RHEL7. У якості гіпервізора для віртуалізації використовується KVM та інструментальний пакет libvirt.

    Встановлення

    Встановити пакунки, необхідні для збірки 

    # yum install gcc libatomic install make python-devel \
        openssl-devel kernel-devel graphviz kernel-debug-devel \
        autoconf automake rpm-build redhat-rpm-config libtool

    Завантажити архів з кодом пакунку в домашню теку та разархівувати його:

    # cd
    # wget http://openvswitch.org/releases/openvswitch-2.4.0.tar.gz
    # tar xzvf openvswitch-2.4.0.tar.gz

    Покласти копію архіва з кодом в теку /root/rpmbuild/SOURCES:

    # mkdir -p /root/rpmbuild/SOURCES
    # cp openvswitch-2.4.0.tar.gz /root/rpmbuild/SOURCES

    Запустити процес збірки:

    # cd openvswitch-2.4.0
    # rpmbuild -bb rhel/openvswitch.spec

    Встановити RPM-пакунок, який був створений внаслідок збірки:

    # yum localinstall /root/rpmbuild/RPMS/x86_64/openvswitch-2.4.0-1.x86_64.rpm

    Скопіювати скрипти керування сервісами в належні місця та налаштувати автоматичний запуск сервісу:

    # cp rhel/usr_lib_systemd_system_openvswitch-nonetwork.service \
        /usr/lib/systemd/system/openvswitch-nonetwork.service
    # cp rhel/usr_lib_systemd_system_openvswitch.service \
        /usr/lib/systemd/system/openvswitch.service
    # systemctl enable openvswitch.service

    Примітка: для того щоб уникнути проблем з запуском сервісу потрібно відімкнути SELinux.

    OVS зберігає свою конфігурацію у власній базі даних, що знаходиться у теці /etc/openvswitch. Щойно встановлений OVS створює пусту базу даних:

    # ovs-vsctl show
    4a2b3832-7f57-43c8-9e56-b80974d4ea40
        ovs_version: "2.4.0"

    Створення базового моста

    Застосування OVS здійснюється шляхом створення мостів, які можна порівняти з типовим Ethernet-комутатором -- до нього під’єднуються інтерфейси, налаштовуються 802.1Q VLAN, виконуються процеси Spaning-Tree Protocol (STP), тощо. За звичай на сервері-носії достатньо створити єдиний OVS-міст:

    # ovs-vsctl add-br ovsbridge0
    # ip link set ovsbridge0 up
    # ip addr show ovsbridge0
    5: ovsbridge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
        link/ether 96:34:45:9c:6e:4e brd ff:ff:ff:ff:ff:ff
        inet6 fe80::9434:45ff:fe9c:6e4e/64 scope link 
           valid_lft forever preferred_lft forever
    # ovs-vsctl show
    ...
        Bridge "ovsbridge0"
            Port "ovsbridge0"
                Interface "ovsbridge0"
                    type: internal
    ...

    Для коректного поводження системи з мостом ovsbridge0 під час перевантажень системи та перезапусків мережевого сервісу необхідно створення файлу /etc/sysconfig/network-scripts/ifcfg-ovsbridge0 з наступним вмістом:

    DEVICE=ovsbridge0
    ONBOOT=yes
    DEVICETYPE=ovs
    TYPE=OVSBridge
    BOOTPROTO=static

    Під’єднання до OVS-моста фізичних інтерфейсів сервера

    Для зв’язку з зовнішньою мережею до OVS-моста потрібно під’єднати фізичні інтерфейси сервера-носія. Гарною практикою є виділення одного фізичного інтерфейсу сервера, який не під’єднується до OVS-моста і слугує виключно для доступу до системи носія (батьківської). В результаті у разі можливих помилок з налаштуванням OVS не буде втрачено зв’язок з батьківською системою.

    Під’єднання до OVS-моста фізичного інтерфейсу:

    # ovs-vsctl add-port ovsbridge0 enp0s3
    # ip link set enp0s3 up
    # ovs-vsctl show
    ...
        Bridge "ovsbridge0"
            Port "ovsbridge0"
                Interface "ovsbridge0"
                    type: internal
            Port "enp0s3"
                Interface "enp0s3"
    ...
    # ip addr show enp0s3
    2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP qlen 1000
        link/ether 08:00:27:5e:db:ba brd ff:ff:ff:ff:ff:ff

    Для збереження налаштувань під час перезавантажень сервера та перезапусків мережевого сервісу необхідно створити файл /etc/sysconfig/network-scripts/ifcfg-enp0s3 з наступним вмістом:

    NAME=enp0s3
    DEVICE=enp0s3
    ONBOOT=yes
    DEVICETYPE=ovs
    TYPE=OVSPort
    OVS_BRIDGE=ovsbridge0
    BOOTPROTO=none
    HWADDR=08:00:27:5e:db:ba

    Примітка:
     якщо ви знехтували порадою про окремий інтерфейс для керування носієм, або на сервері взагалі лише один фізичний інтерфейс, налаштування IP-адреси необхідно перенести з фізичного інтерфейсу на інтерфейс мосту:

    # ip addr del 192.168.1.128/24 dev enp0s3
    # ip addr add 192.168.1.128/24 dev ovsbridge0
    # ip route add default via 192.168.1.1

    Відповідно з файлу /etc/sysconfig/network-scripts/ifcfg-enp0s3 до файлу /etc/sysconfig/network-scripts/ifcfg-ovsbridge0 необхідно перенести наступні рядки (чи подібні):

    IPADDR=192.168.1.128
    NETMASK=255.255.255.0
    GATEWAY=192.168.1.1

    Зрозуміло, що останні дії виконуються з фізичної консолі носія, оскільки зв’язок з ним через мережу тимчасово буде втрачено.

    Під’єднання до OVS інтерфейсів віртуальних машин

    У якості посередника між OVS та інтерфейсами віртуальних машин використовуються віртуальні мережі. Для створення вітуальної мережі, пов’язаної з інтерфейсом ovsbridge0, необхідно підготувати, наприклад в своїй домашій теці, XML-файл з іменем, наприклад, mgmt.xml, з наступним вмістом:

    <network>
      <name>mgmt</name>
      <forward mode='bridge'/>
      <bridge name='ovsbridge0' />
      <virtualport type='openvswitch'/>
    </network>

    Використовуючи зазначений XML-файл створюється віртуальна мережа mgmt:

    # virsh net-define mgmt.xml
    # virsh net-start mgmt
    # virsh net-autostart mgmt
    # virsh net-list
     Name                 State      Autostart     Persistent
    ----------------------------------------------------------
     mgmt                 active     yes           yes

    До створеної мережі може бути під’єднано інтерфейс віртуальної машини:

    # virsh list --all
     Id    Name                           State
    ----------------------------------------------------
      -     vhost                           shut off

    # virsh domiflist vhost
    Interface  Type       Source     Model       MAC
    -------------------------------------------------------

    # virsh attach-interface vhost network mgmt --model virtio --config
    Interface attached successfully

    # virsh domiflist vhost
    Interface  Type       Source     Model       MAC
    -------------------------------------------------------
    -          network    mgmt      virtio      52:54:00:7a:02:61

    # virsh start vhost
    Domain vhost started

    # virsh domiflist vhost
    Interface  Type       Source     Model       MAC
    -------------------------------------------------------
    vnet0      bridge     mgmt       virtio      52:54:00:7a:02:61

    # ip addr show vnet4
    8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UNKNOWN qlen 500
        link/ether fe:54:00:7a:02:61 brd ff:ff:ff:ff:ff:ff
        inet6 fe80::fc54:ff:fe7a:261/64 scope link 
           valid_lft forever preferred_lft forever

    # ovs-vsctl show
    ...
        Bridge "ovsbridge0"
            Port "ovsbridge0"
                Interface "ovsbridge0"
                    type: internal
    ...
            Port "vnet0"
                Interface "vnet0"
    ...

    Примітка: інтерфейс було додано до віртуальної машини, яка знаходилася у вимкненому стані. Після старту віртуальний інтерфейс автоматично з’являється серед пристроїв цієї віртуальної машини.

    Використання 802.1Q VLAN

    Можливим є використання сервера-носія з віртуальними машинами у мережі, в якій налаштовано віртуальні локальні мережі (VLAN). Наприклад, може виникнути потреба під’єднання інтерфейсів різних віртуальних машин до різних VLAN. В цьому випадку фізичний інтерфейс носія під’єднується до транкового порту зовнішнього комутатора, через який передаються фрейми різних VLAN з відповідними тегами. Розглянемо, як під’єднати до VLAN інтерфейс віртуальної машини.

    На OVS-мості створюється підпорядкований псевдо-міст (fake bridge), що пов’язується з потрібною VLAN (в даному випадку VLAN104):

    # ovs-vsctl add-br ovsvlan104 ovsbridge0 104
    # ip link set ovsvlan104 up
    # ovs-vsctl show
        Bridge "ovsbridge0"
    ...
            Port "ovsvlan104"
                tag: 104
                Interface "ovsvlan104"
                    type: internal
    ...
    # ip addr show ovsvlan104
    10: ovsvlan104: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
        link/ether 06:a2:0f:cf:0d:47 brd ff:ff:ff:ff:ff:ff
        inet6 fe80::4a2:fff:fecf:d47/64 scope link 
           valid_lft forever preferred_lft forever

    Для збереження налаштувань під час перезавантажень сервера та перезапусків мережевого сервісу необхідно створити файл /etc/sysconfig/network-scripts/ifcfg-ovsvlan104 з наступним вмістом:

    DEVICE=ovsvlan104
    ONBOOT=yes
    DEVICETYPE=ovs
    TYPE=OVSBridge
    BOOTPROTO=static
    OVS_OPTIONS="ovsbridge0 104"

    Для створення вітуальної мережі, пов’язаної з VLAN104, підготувати XML-файл vlan104.xml з наступним вмістом:

    <network>
      <name>vlan104</name>
      <forward mode='bridge'/>
      <bridge name='ovsvlan104' />
      <virtualport type='openvswitch'/>
    </network>

    Створити віртуальну мережу vlan104:

    # virsh net-define vlan104.xml
    # virsh net-start vlan104
    # virsh net-autostart vlan104
    # virsh net-list
     Name                 State      Autostart     Persistent
    ----------------------------------------------------------
     mgmt                 active     yes           yes
     vlan104              active     yes           yes

    Для під’єднання до нової віртуальної мережі створимо новий інтерфейс віртуальної машини, яка вже знаходиться в активному стані.

    # virsh list
     Id    Name                           State
    ----------------------------------------------------
      1     vhost                          running

    # virsh attach-interface vhost network vlan104 --model virtio --live
    Interface attached successfully

    # virsh attach-interface vhost network vlan104 --model virtio --config
    Interface attached successfully

    # virsh domiflist vhost
    Interface  Type       Source     Model       MAC
    -------------------------------------------------------
    vnet0      bridge     mgmt       virtio      52:54:00:7a:02:61
    vnet1      bridge     vlan104    virtio      52:54:00:c6:60:1c

    # ovs-vsctl show
    ...
        Bridge "ovsbridge0"
    ...
            Port "ovsvlan104"
                tag: 104
                Interface "ovsvlan104"
                    type: internal
            Port "vnet1"
                tag: 104
                Interface "vnet1"
    ...


    Налаштування та використання нового інтерфейсу, який щойно з’явився в віртуальній машині vhost може здійснюватися відразу без перезавантаження машини.

    Корисні поради

    Під час відлагодження конфігурації мережі замість команди systemctl restart network, яка дає вкрай обмежену інформацію про результат виконання, зручно користуватися командою:

    # SYSTEMCTL_SKIP_REDIRECT=1 service network restart
    Shutting down interface enp0s3:                            [  OK  ]
    Shutting down interface ovsbridge0:                        [  OK  ]
    Shutting down loopback interface:                          [  OK  ]
    Bringing up loopback interface:                            [  OK  ]
    Bringing up interface enp0s3:                              [  OK  ]
    Bringing up interface ovsbridge0:                          [  OK  ]

    Джерела

    вівторок, 3 листопада 2015 р.

    Електронна книга: Big Data Explained, Analysed, Solved

    Популярно про Big Data від Canonical -- зареєструйтеся та отримайте електронну книгу, автором якої є системний аналітик компанії Canonical, відомої своїм продуктом Ubuntu Linux.

    понеділок, 2 листопада 2015 р.

    Vagrant: зручний інструмент розробника

    Vagrant -- система для автоматизації роботи з віртуальними машинами. Дозволяє оперативно створювати нові віртуальні машини з потрібною конфігурацією та встановленим програмним забезпеченням. Особливо зручна для розробників застосувань та інженерів, які здійснюють моделювання систем. Можливе використання у колективній роботі.
    Підтримує багато систем віртуалізації (провайдерів). Має підтримку Virtualbox в базовому комплекті. Підтримка інших провайдерів забезпечується встановленням додатків. Рекомендованим провайдером з точки зору надійності та продуктивності є VMWare.
    Для налаштування віртуальних машин можуть використовуватися системи керування конфігураціями на кшталт Chef або Puppet, чи добірка шелл-скриптів.
    Повний опис потрібного ПЗ та конфігурація віртуальної машини зберігається в файлі Vagrantfile. Використовуючи один Vagrantfile можна створювати довільну кількість ідентичних віртуальних машин.
    Для початкового створення віртуальних машин використовується добірка заздалегідь підготовлених образів -- немає потреби щоразу встановлювати ОС з нуля. Базові образи можуть бути завантажені зі спеціальних репозиторіїв. Так само можливо використовувати свої власні базові образи.
    Приклад репозиторію базових образів: https://atlas.hashicorp.com/boxes/search. Наявні образи Ubuntu, Debian, CentOS, CoreOS, Windows. Можливо завантажувати свої образи в публічні репозиторії.
    Запуск та налаштування vagrant віртуальної машини забезпечується файлом Vagrantfile для цієї машини. Зокрема, в зазначеному файлі вказується базовий образ, який слід використовувати. Також можна вказати скрипт ініціалізації, в якому будуть встановлені потрібні пакети і запущені необхідні сервіси. Доступ ззовні до сервісів можливий, наприклад за допомогою перенаправлення портів (port forwarding).
    Базова директорія для даної віртуальної машини синхронізується з директорією /home/vagrant/sync в файловій системі цієї машини, що дає можливість обмінюватися файлами з машиною.
    Мережеві інтерфейси віртуальної машини можуть автоматично отримувати IP-адресу, або мати статичне налаштування. Топологічно вони можуть бути під’єднані через мостове з’єднання (bridge) до інтерфейсів батьківської машини або використовувати батьківську машину у якості NAT-шлюзу.
    До створеної віртуальної машини можливо надати доступ з Інтернет. Доступ може здійснюватися за протоколами HTTP, SSH або іншими. Для надання доступа вкористовується обліковий запис на сайті HashiCorp's Atlas.
    Активна віртуальна машина може бути поставлена на паузу зі збереженням стану на жорсткому диску (suspended), зупинена з виконанням процедур завершення роботи (halted) або знищена подібно до миттєвого відімкнення живлення (destroyed).

    Джерело:

    середа, 28 жовтня 2015 р.

    Безкоштовна електронна книга: The Docker & Container Ecosystem

    Скористуйтеся можливістю завантажити безкоштовну електронну книгу The Docker & Container Ecosystem. Книга містить результати опитувань, проведених O’Reilly Media, стосовно сучасного використання технології Docker контейнерів.

    вівторок, 27 січня 2015 р.

    Популярно про переваги SDN

    В своїй статті Greg Ferro визначив чотири основні переваги технології програмно визначених мереж (Software Defined Networking, SDN), завдяки яким ця технологія отримує чимдалі більшу популярність і поширення. Ось ці переваги:
    • побудову мереж на основі SDN можна почати відразу зараз без потреби заміни елементів наявної мережевої інфраструктури
    • SDN надає можливість почати з невеликого проекту і надалі поступово збільшувати масштаб впровадження цієї технології
    • впровадження SDN здійснюється на певній частині типового дата-центру, не заторкуючи інші частини мережі, отже вирішення питань підтримки операцій та безпеки не викликає ускладнень
    • розвиток мережі на основі SDN здійснюється як послідовність невеликих змін, отже ІТ-директори або керівники підприємств не повинні шукати джерела для бюджету на коштовні модифікації мережі
    В статті також наведено прогнози щодо впровадження SDN в глобальних мережах, зокрема, на межі між мережами підприємств, каналів до провайдерів, з’єднаннях міх географічно рознесеними сегментами мережі підприємства.

    Посилання:

    вівторок, 20 січня 2015 р.

    Brocade випускає контролер SDN базований на відкритому коді

    20 січня компанія Brocade оголосила про випуск свого контролера SDN, який базується на продукті з відкритим кодом OpenDayLight. Новий контролер надає можливість сервіс-провайдерам та підприємствам безкоштовно отримати досвід використання SDN.

    Ліцензія передбачає безкоштовне використання контролера протягом одного року з підтримкою до 5 мережевих вузлів. Ліцензія для комерційного використання коштує $100 за кожен мережевий вузол за рік. Протягом  однорічного випробувального терміну користувачі мають доступ до технічної підтримки 24х7.


    Посилання:
    Дивіться також:

    неділя, 18 січня 2015 р.

    Віртуалізація чи хмара?

    Декілька тез за результатами прочитання статті Luke Huckaba. Virtualization Or Cloud? 5 Questions To Help You Decide.

    Чи є сенс у протиставленні віртулізації та хмарних інфраструктур, адже віртуалізація є базовою і невід’ємною технологією для створення хмар? Можна для спрощення уявити, що хмарні технології -- це віртуалізація плюс технології розвинутого гнучкого і всебічного керування компонентами, або оркестровка (orchestration). Для створення хмар потрібні і віртуалізація і оркестровка. Але в простіших випадках оркестровка непотрібна і достатньо віртуалізації. Тож питання полягає в тому, де та межа, коли однієї віртуалізації вже замало, і час реалізувати повноцінну хмару?

    • Змінний профіль навантаження
    Якщо ваша обчислювальна система характеризується монотонним, предбачуваним завантаженням, віртуалізації буде достатньо. Добре спланований розподіл навантаження з урахуванням вимог щодо відмовостійкості та епізодичних сплесків обмеженого рівня забезпечить стійке і надійне функціювання системи з оптимальним використанням апаратних ресурсів.

    Але, якщо сплески завантаження є частими і сягають декількох порядків, якщо інтервали пікового навантаження змінюються тривалими інтервалами малого завантаження (або навіть паузами у обчисленнях) і вас не влаштовує утримання на балансі апаратного забезпечення, що простоює, протягом цього часу, вам потрібна хмара.

    • Швидкість забезпечення ресурсів (provisioning)
    Надзвичайно важливий фактор у разі як потрібно оперативно збільшувати наявні обчислювальні потужності шляхом створення множини нових готових до застосування віртуальних машин, а також швидко позбавлятися ресурсів, що не потрібні (особливо, якщо за ці ресурси здіймається почасова сплата). Кількість створюваних та вилучених віртуальних машин може сягати десятків чи навіть сотень.

    • Автоматизація технологічних дій
    Рутинні технологічні дії повинні мати високий ступінь автоматизації. Це означає, що для виконання найбільш частих і критично важливих операцій достатньо виконання тривіальних дій у інтегрованому графічному інтерфейсі адміністратора. Вочевидь, технологічні процедури, що складаються з послідовності дій (хай навіть ретельно задокументовані), які виконуються в командному рядку з правами супер-користувача, чи саморобні shell- та perl-скрипти не відповідають належному рівню автоматизації для хмар.
    • Делегування функцій керування користувачам
    В випадках, коли провайдер надає свої ресурси для створення приватних хмар користувачів, доцільно надати можливості і повноваження користувачам для керування своїми хмарними ресурсами. Виконання технологічних операцій в приватній хмарі виконавцями провайдера за запитами від користувача не забезпечує належний рівень оперативності та гнучкості керування. Користувачі повинні мати якомога більші функції для керування своїми хмарами, але не мати вплив на ресурси інших користувачів або провайдера. Вочевидь, при делегуванні функцій керування постає питання про наявність відповідної кваліфікації користувача, аби використанням наданих функцій керування не зашкодити самому собі. Одним зі шляхів приведення у відповідність складності вирішуваних задач і кваліфікації виконавця є високий рівень автоматизації, завдяки якому складні операції здатен виконувати користувач обмеженної кваліфікації.
    • Масштабованість
    Здатність швидкого збільшення обсягу задіяних технологічних ресурсів без зміни впроваджених технологічних процесів. Фактично, мова йде про нарощування потужності шляхом додавання однотипних апаратних компонент -- серверів та комутаторів, які з’єднуються з загальною інфраструктурою по стандартним схемам підключення зі стандартними налаштуваннями. Можливо впровадження автоматичної масштабованості, за якої апаратні компоненти, що перебувають у резерві, автоматично долучаються до використання, та навпаки, звільнені від використання знов переводяться у резерв.
    • Створення віртуальних мереж
    Хмари надають платформу для віртуальних мереж. Необхідність створення віртуальних мереж є важливим фактором для переходу до хмари. Доречно, щоб всі раніше зазначені ознаки --  гнучкий профіль завантаження, швидкість забезпечення, автоматизація, делегування функцій керування та масштабованість в рівній мірі стосувалися компонентів віртуальних мереж, створених у хмарі.

    Посилання:

    середа, 7 січня 2015 р.

    Використання YUM для встановлення конкретної версії MySQL/Percona

    Стисле резюме статті, яка сподобалася тим, що окрім конкретного застосування для гнучкого контролю за версіями встановленого сервера баз даних (БД) MySQL або Percona, продемонстровані цікаві прийоми роботи з YUM -- менеджера програмних пакетів для систем Linux сумісних з RHEL (RPM).

    Оригінал статті: Using YUM to install specific MySQL/Percona Server versions. January 5, 2015 by Przemysław Malkowski

    Задача: встановити певну (не найостаннішу) версію сервера БД Percona Server та захиститися від автоматичного оновлення на свіжішу версію.

    Можливі шляхи вирішення:
    • завантажити потрібні файли RPM та встановити "вручну"
    • створити власний RPM-репозиторій, якій міститиме лише потрібні версії пакетів
    • розгортати сервери БД зі заздалегідь підготовлених образів
    • визначити версію встановленого пакету засобами програми yum
    Стаття демонструє останній з зазначених методів.

    Розглянемо систему CentOS6, налаштовану на роботу з репозиторієм Percona:
    [root@localhost ~]# yum repolist
    repo id                         repo name                                           status
    base                            CentOS-6 - Base                                      6,518
    extras                          CentOS-6 - Extras                                       36
    percona-release-noarch          Percona-Release YUM repository - noarch                 26
    percona-release-x86_64          Percona-Release YUM repository - x86_64                432
    updates                         CentOS-6 - Updates                                     530
    (...)
    
    [root@localhost ~]# yum -q list available --showduplicates Percona-Server-server-56.x86_64
    Available Packages
    Percona-Server-server-56.x86_64       5.6.13-rel61.0.461.rhel6      percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.14-rel62.0.483.rhel6      percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.15-rel63.0.519.rhel6      percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.16-rel64.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.16-rel64.1.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.16-rel64.2.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.17-rel65.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.17-rel66.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.19-rel67.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.20-rel68.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.21-rel69.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.21-rel70.0.el6            percona-release-x86_64
    Percona-Server-server-56.x86_64       5.6.21-rel70.1.el6            percona-release-x86_64
    
    Встановлюємо обрану версію (5.6.19), яка не є останньою:
    [root@localhost ~]# yum -q install Percona-Server-server-56-5.6.19-rel67.0.el6 Percona-Ser
    ver-client-56-5.6.19-rel67.0.el6 Percona-Server-shared-56-5.6.19-rel67.0.el6
     
    ==========================================================================================
    Package                       Arch     Version               Repository              Size
    ==========================================================================================
    Installing:
    Percona-Server-client-56     x86_64    5.6.19-rel67.0.el6    percona-release-x86_64  6.8 M
    Percona-Server-server-56     x86_64    5.6.19-rel67.0.el6    percona-release-x86_64   19 M
    Percona-Server-shared-56     x86_64    5.6.19-rel67.0.el6    percona-release-x86_64  721 k
     
    Transaction Summary
    ==========================================================================================
    Install       3 Package(s)
     
    Is this ok [y/N]: y
    (...)
     
    [root@localhost ~]# rpm -qa|grep Percona
    Percona-Server-server-56-5.6.19-rel67.0.el6.x86_64
    Percona-Server-client-56-5.6.19-rel67.0.el6.x86_64
    Percona-Server-shared-56-5.6.19-rel67.0.el6.x86_64
    
    Якщо потрібно, пізніше ми можемо замінити встановлену версію на ту, яка була перед нею:
    [root@localhost ~]# service mysql status
    SUCCESS! MySQL (Percona Server) running (1998)
    [root@localhost ~]# service mysql stop
    Shutting down MySQL (Percona Server).. SUCCESS!
     
    [root@localhost ~]# yum -q downgrade Percona-Server-server-56.x86_64 Percona-Server-client
    -56.x86_64 Percona-Server-shared-56.x86_64
     
    ==========================================================================================
    Package                       Arch     Version               Repository              Size
    ==========================================================================================
    Downgrading:
    Percona-Server-client-56      x86_64   5.6.17-rel66.0.el6    percona-release-x86_64  6.8 M
    Percona-Server-server-56      x86_64   5.6.17-rel66.0.el6    percona-release-x86_64   19 M
    Percona-Server-shared-56      x86_64   5.6.17-rel66.0.el6    percona-release-x86_64  720 k
     
    Transaction Summary
    ==========================================================================================
    Downgrade     3 Package(s)
     
    Is this ok [y/N]: y
    Giving mysqld 5 seconds to exit nicely
    (...)
     
    [root@localhost ~]# rpm -qa|grep Percona
    Percona-Server-shared-56-5.6.17-rel66.0.el6.x86_64
    Percona-Server-server-56-5.6.17-rel66.0.el6.x86_64
    Percona-Server-client-56-5.6.17-rel66.0.el6.x86_64
    
    Можемо перейти навіть на декілька версій назад:
    [root@localhost ~]# yum -q downgrade Percona-Server-server-56-5.6.15-rel63.0.519.rhel6 Per
    cona-Server-client-56-5.6.15-rel63.0.519.rhel6 Percona-Server-shared-56-5.6.15-rel63.0.519
    .rhel6
     
    ==========================================================================================
    Package                    Arch    Version                   Repository              Size
    ==========================================================================================
    Downgrading:
     Percona-Server-client-56  x86_64  5.6.15-rel63.0.519.rhel6  percona-release-x86_64  6.5 M
     Percona-Server-server-56  x86_64  5.6.15-rel63.0.519.rhel6  percona-release-x86_64   18 M
     Percona-Server-shared-56  x86_64  5.6.15-rel63.0.519.rhel6  percona-release-x86_64  691 k
     
    Transaction Summary
    ==========================================================================================
    Downgrade     3 Package(s)
     
    Is this ok [y/N]: y
    Giving mysqld 5 seconds to exit nicely
    (...)
    
    До речі, зверніть увагу на зміну вигляду результату виконання команди:
    yum -q list available --showduplicates Percona-Server-server-56.x86_64
    Всі версії, новіші за встановлену, позначені жирним шрифтом.
    Операцію по заміні встановленої версії пакунку на старішу можна також виконати, використовуючи здатність yum до виконання декількох операцій за одну транзакцію:
    [root@localhost ~]# yum shell
    Loaded plugins: fastestmirror, security
    Setting up Yum Shell
    > remove Percona-Server-shared-56 Percona-Server-server-56 Percona-Server-client-56
    Setting up Remove Process
    > install Percona-Server-server-56-5.6.15-rel63.0.519.rhel6 Percona-Server-client-56-5.6.1
    5-rel63.0.519.rhel6 Percona-Server-shared-56-5.6.15-rel63.0.519.rhel6
    (...)
    Setting up Install Process
    > run
    --> Running transaction check
    ---> Package Percona-Server-client-56.x86_64 0:5.6.15-rel63.0.519.rhel6 will be installed
    ---> Package Percona-Server-client-56.x86_64 0:5.6.17-rel66.0.el6 will be erased
    ---> Package Percona-Server-server-56.x86_64 0:5.6.15-rel63.0.519.rhel6 will be installed
    ---> Package Percona-Server-server-56.x86_64 0:5.6.17-rel66.0.el6 will be erased
    ---> Package Percona-Server-shared-56.x86_64 0:5.6.15-rel63.0.519.rhel6 will be obsoleting
    ---> Package Percona-Server-shared-56.x86_64 0:5.6.17-rel66.0.el6 will be erased
    (...)
    ==========================================================================================
    Package                    Arch    Version                   Repository              Size
    ==========================================================================================
    Installing:
    Percona-Server-client-56  x86_64   5.6.15-rel63.0.519.rhel6  percona-release-x86_64  6.5 M
    Percona-Server-server-56  x86_64   5.6.15-rel63.0.519.rhel6  percona-release-x86_64   18 M
    Percona-Server-shared-51  x86_64   5.1.73-rel14.12.624.rhel6 percona-release-x86_64  2.1 M
         replacing  mysql-libs.x86_64 5.1.73-3.el6_5
    Percona-Server-shared-56  x86_64   5.6.15-rel63.0.519.rhel6  percona-release-x86_64  691 k
         replacing  mysql-libs.x86_64 5.1.73-3.el6_5
    Removing:
    Percona-Server-client-56  x86_64   5.6.17-rel66.0.el6        @percona-release-x86_64  33 M
    Percona-Server-server-56  x86_64   5.6.17-rel66.0.el6        @percona-release-x86_64  86 M
    Percona-Server-shared-56  x86_64   5.6.17-rel66.0.el6        @percona-release-x86_64 3.4 M
     
    Transaction Summary
    ==========================================================================================
    Install       4 Package(s)
    Remove        3 Package(s)
     
    Total download size: 27 M
    Is this ok [y/N]: y
    (...)
    Removed:
      Percona-Server-client-56.x86_64 0:5.6.17-rel66.0.el6
      Percona-Server-server-56.x86_64 0:5.6.17-rel66.0.el6          
      Percona-Server-shared-56.x86_64 0:5.6.17-rel66.0.el6          
     
    Installed:
      Percona-Server-client-56.x86_64 0:5.6.15-rel63.0.519.rhel6
      Percona-Server-server-56.x86_64 0:5.6.15-rel63.0.519.rhel6    
      Percona-Server-shared-51.x86_64 0:5.1.73-rel14.12.624.rhel6
      Percona-Server-shared-56.x86_64 0:5.6.15-rel63.0.519.rhel6    
     
    Replaced:
      mysql-libs.x86_64 0:5.1.73-3.el6_5                                                                                            
     
    Finished Transaction
    > quit
    Leaving Shell
    [root@localhost ~]# rpm -qa|grep Percona
    Percona-Server-shared-56-5.6.15-rel63.0.519.rhel6.x86_64
    Percona-Server-client-56-5.6.15-rel63.0.519.rhel6.x86_64
    Percona-Server-shared-51-5.1.73-rel14.12.624.rhel6.x86_64
    Percona-Server-server-56-5.6.15-rel63.0.519.rhel6.x86_64
    
    Звертаємо увагу на те, що транзакція відбудеться навіть у разі, якщо в системі встановлено пакунки, які залежать від тих, які перевстановлюються.
    Нарешті потрібно захиститися від можливості заміни версії пакунків на найновіші під час виконання команди
    yum -q update
    :
    [root@localhost ~]# yum -q update
     
    ==========================================================================================
    Package                    Arch    Version                   Repository              Size
    ==========================================================================================
    Updating:
    Percona-Server-client-56   x86_64  5.6.21-rel70.1.el6        percona-release-x86_64  6.4 M
    Percona-Server-server-56   x86_64  5.6.21-rel70.1.el6        percona-release-x86_64   19 M
    Percona-Server-shared-56   x86_64  5.6.21-rel70.1.el6        percona-release-x86_64  721 k
     
    Transaction Summary
    ==========================================================================================
    Upgrade       3 Package(s)
     
    Is this ok [y/N]: N
    Exiting on user Command
    
    Для захисту використовуємо функціональність додатку yum-plugin-versionlock:
    [root@localhost ~]# yum versionlock Percona-Server-server-56 Percona-Server-client-56 Perc
    ona-Server-shared-56
    Loaded plugins: fastestmirror, security, versionlock
    Adding versionlock on: 0:Percona-Server-server-56-5.6.15-rel63.0.519.rhel6
    Adding versionlock on: 0:Percona-Server-client-56-5.6.15-rel63.0.519.rhel6
    Adding versionlock on: 0:Percona-Server-shared-56-5.6.15-rel63.0.519.rhel6
    versionlock added: 3
    [root@localhost ~]# yum update
    Loaded plugins: fastestmirror, security, versionlock
    Setting up Update Process
    (...)
    No Packages marked for Update
    
    Встановлені версії пакунків не буде оновлено, якщо не буде очищено перелік обов’язкових версій:
    [root@localhost ~]# yum versionlock clear
    ...
    [root@localhost ~]# yum -q versionlock list
    0:Percona-Server-server-56-5.6.15-rel63.0.519.rhel6.*
    0:Percona-Server-client-56-5.6.15-rel63.0.519.rhel6.*
    0:Percona-Server-shared-56-5.6.15-rel63.0.519.rhel6.*
    [root@localhost ~]# yum versionlock delete '0:Percona-Server-client-56-5.6.15-rel63.0.519.rhel6.*'
    Loaded plugins: fastestmirror, security, versionlock
    Deleting versionlock for: 0:Percona-Server-client-56-5.6.15-rel63.0.519.rhel6.*
    versionlock deleted: 1
    [root@localhost ~]# yum -q versionlock list
    0:Percona-Server-server-56-5.6.15-rel63.0.519.rhel6.*
    0:Percona-Server-shared-56-5.6.15-rel63.0.519.rhel6.*
    [root@localhost ~]# yum -q update
    ==========================================================================================
    Package                    Arch    Version                   Repository              Size
    ==========================================================================================
    Updating:
     Percona-Server-client-56  x86_64  5.6.21-rel70.1.el6        percona-release-x86_64  6.4 M
    Transaction Summary
    ==========================================================================================
    Upgrade       1 Package(s)
    
    Is this ok [y/N]:
    
    Наявність можливості встановлення конкретної версії пакунків з yum стає в нагоді під час інтеграції з системами керування програмним забезпеченням на зразок Chef, Puppet або Ansible. Фіксування версії пакунків Percona для Chef задається таким блоком:
    pkgs = ["Percona-Server-client-56","Percona-Server-shared-56","Percona-Server-server-56","Percona-Server-56-debuginfo"]
    pkgs.each do |pkg|
            yum_package pkg do
            version "5.6.20-rel68.0.el6"
            allow_downgrade true
        end
    end