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

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

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

• Змінний профіль навантаження

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

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

• Швидкість забезпечення ресурсів (provisioning)

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

• Автоматизація технологічних дій

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

• Делегування функцій керування користувачам

В випадках, коли провайдер надає свої ресурси для створення приватних хмар користувачів, доцільно надати можливості і повноваження користувачам для керування своїми хмарними ресурсами. Виконання технологічних операцій в приватній хмарі виконавцями провайдера за запитами від користувача не забезпечує належний рівень оперативності та гнучкості керування. Користувачі повинні мати якомога більші функції для керування своїми хмарами, але не мати вплив на ресурси інших користувачів або провайдера. Вочевидь, при делегуванні функцій керування постає питання про наявність відповідної кваліфікації користувача, аби використанням наданих функцій керування не зашкодити самому собі. Одним зі шляхів приведення у відповідність складності вирішуваних задач і кваліфікації виконавця є високий рівень автоматизації, завдяки якому складні операції здатен виконувати користувач обмеженної кваліфікації.

• Масштабованість

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

• Створення віртуальних мереж

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

Посилання:

• Virtualization Or Cloud? 5 Questions To Help You Decide. Filed in Cloud Industry Insights on August 13th, 2014 by Luke Huckaba
   

Використання 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

Контролери SDN: хто що робить

Пропоную вашій увазі стисле резюме однойменної статті Мітча Вагнера.

Контролер є логічним центром керування мережі SDN, який керує комутаторами через свій "південний" інтерфейс і взаємодіє з застосуваннями через "північний" інтерфейс.

В чистому вигляді контролер SDN концентрує весь інтелект: комутатори є найпростішими пристроями, що здатні використовуватися відразу після придбання (commercial off-the-shelf, COTS), керування ними здійснює контролер.

Оператори, які вважають зазначений підхід занадто обмеженим, можуть рухатися в напрямку "накладених" або оверлейних (overlay) мереж, запропонованих Cisco Systems, VMWare та іншими виробниками. Оверлейні мережі є програмним прошарком поверх існуючих фізичних мереж. У якості комутаторів можуть використовуватися COTS пристрої, або більш просунуті з фірмовою функціональністю від виробників.

Найчастіше наразі контролери SDN можна зустріти у дата-центрах, втім, їх також використовують у глобальних мережах підприємств (wide area enterprise networks), вони отримують перспективи в глобальних мережах провайдерів послуг, оскільки забезпечують технологію операторського класу, та по мірі того, як визначаються типові сценарії (business cases) їх використання.

Згідно з теорією, SDN дозволяє створювати програмовані мережі, які є гнучкішими та дешевшими у використанні.

Одне з найважливіших питань під час впровадження SDN контролерів в дата-центрах та опраторських мережах є наскільки в дійсності вони здатні інтегруватися (interoperate) з іншими компонентами мережі від різних виробників. Одна з найголовніших обіцянок SDN була звільнення операторів від замкнення на певного постачальника.

Оператори бажають самостійно комплектувати мережі і здійснювати інтеграцію.

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

Далі наведено перелік відомих нам контролерів SDN -- як комерційних, так і з відкритим кодом.

Виробники	Продукти	Ліцензія	Нотатки
Adara Networks	Sky, Horizon	комерційні	розподілений контролер SDN, базований на протоколі OpenFlow, та "мета-контролер" для керування в мережах SDN з компонентами від різних виробників (multi-vendor) та різними потоколами (multi-protocol)
Big Switch Networks	Big Network Controller	комерційний	контролер SDN, базований на протоколі OpenFlow
Brocade Communications Systems	Vyatta Controller	відкритий код	контролер SDN, базований на специфікації OpenDaylight
Calient Technologies	Optical Topology Management Controller	відкритий код	побудований на коді OpenDaylight
Ciena	Agility Multilayer WAN Controller	комерційний	орієнтований на роботу в умовах непередбачуваних сплесків трафіку в глобальних мережах або від користувачів хмарних сервісів
Cisco Systems	Application Policy Infrastructure Controller (APIC)	комерційний	орієнтований на роботу в архітектурі SDN з інфраструктурою, орієнтованою на застосування (Application Centric Infrastructure SDN architecture) Cisco
CloudGenix	Software-Defined Enterprise WAN (SDEwan)	комерційний	знаходиться в стадії бета-версії
ConteXtream	ContexNet	комерційний	складається з двох компонентів: ContexMap та ContexControl
Coriant	Transcend SDN Solution	комерційний	містить Transport Controller, Packet Controller та SDN Network Orchestrator
CPlane Networks	CPlane Networks Controller	комерційний	контролер для середовища OpenStack
Dell	Active Fabric Controller	комерційний	контролер для середовища OpenStack та протоколу OpenFlow
Extreme Networks	Extreme OneController	комерційний	базований на OpenDaylight
Hewlett-Packard (HP)	HP Virtual Application Networks SDN Controller	комерційний	контролер для керування мережами з протоколом OpenFlow
Huawei Technologies	Smart Network Controller (відомий також як Smart OpenFlow Controller)	комерційний	інтегрується з системою підтримки (orchestration) від Netmatrix, підтримує протоколи OpenFlow, PCE, Netconf та BGP
IBM Corp.	Programmable Network Controller	комерційний	контролер для керування мережами з протоколом OpenFlow
Inocybe Technologies	Infrastructure Controller	комерційний	контролер для SDN та хмарних середовищ на основі OpenDaylight та OpenStack
Juniper Networks	NorthStar та OpenContrail	комерційний	контролери SDN власної розробки та придбаний
NEC America Inc.	ProgrammableFlow SDN Controller	комерційний	перший комерційний контролер для OpenFlow, "контролер контролерів"
Nuage (дочірній проект Alcatel-Lucent)	Virtual Services Controller	комерційний	контролер для керування платформою віртуалізованих послуг Nuage (Nuage's Virtualized Services Platform)
Pica8	RYU OpenFlow	відкритий код	контролер є компонентом стартового набору для SDN (SDN Starter Kit)
Plexxi	Plexxi Control	комерційний	контролер для дата-центрів
VMware	NSX Controller	комерційний	контролер вбудований в платформу VMWare і недоступний як самостійний продукт
Project Floodlight	Floodlight Open SDN Controller	відкритий код, ліцензія Apache	створений компанією Big Switch Networks контролер для OpenFlow
OpenContrail	OpenContrail Controller	відкритий код	спонсорований компанією Juniper Networks "логічно зосереджений та фізично розподілений" контролер для SDN, віртуальний маршрутизатор, центтр аналітики
NOXRepo	NOX & POX	відкритий код	контролер для OpenFlow, призначений для створення застосувань з метою дослідження та навчання
OpenDaylight Project	Helium	відкритий код	відкрита платформа для SDN та NFV
ON.Lab	SDN Open Network Operating System (ONOS)	відкритий код	компоненти для SDN продуктів з відкритим кодом
Stanford University	Beacon	відкритий код	крос-платформений модульний контролер OpenFlow на Java

Джерело:

• Who Does What: SDN Controllers. Mitch Wagner, West Coast Bureau Chief, Light Reading, 12/5/2014