вівторок, 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