GNS3: тепер з підтримкою комутації!

Остання новина від GNS3: емулятор тепер підтримує комутацію! Насправді, як зазначено, комутація підтримувалася вже давно, її лише важко було налаштувати. В новій версії GNS3 1.0 використання комутації спрощено. Обсяг підтримки достатній для практики за програмою CCNP SWITCH. Нова версія з'явиться у відкритому доступі наприкінці 2014 р., проте можливість отримати доступ до попередніх збірок системи буде вже з 20 листопада. Доступ буде надаватися за системою запрошень (invites).

Mapping of Address and Port (MAP): ще одна технологія для співіснування протоколів IPv4 та IPv6

Нещодавно Cisco виклала на своєму сайті статтю про технологію Technical Guide to Mapping of Address and Port (MAP). З якоїсь причини за декілька днів ця стаття зникла з сайту і за наведеним посиланням ви вже її не знайдете (даю посилання на випадок, якщо вилучення було помилковим і стаття незабаром з'явиться знову на старому місці). Втім, я встиг зробити нотатки :-) Пропоную стисле резюме.

Запропонована Cisco технологія MAP призначена для використання в мережах доступу Інтернет-провайдерів і покликана забезпечити  доступність для користувачів IPv4-ресурсів в умовах, коли транспортну мережу провайдера вже переведено повністю на IPv6. Рішення базується на перетворенні IPv4-пакетів у IPv6-пакети для передачі по IPv6-мережі і зворотньому перетворені на виході з цієї мережі.

Перетворення базується на збереженні інформації про L3-адреси та номери TCP/UDP L4-портів IPv4-пакетів у адресах та портах IPv6-пакетів (звідси назва -- mapping of address and port, тобто відображення адрес та портів). Пристрої на боці користувача (Customer Edge, CE) та маршрутизатор на кордоні провайдерської мережі (Border Relay, BR) сумісно здійснюють MAP. Користувачі отримують підтримку як IPv4, так і IPv6, в той час, як по мережі провайдера передаються лише пакети IPv6.

У технології MAP є два різновиди:

• MAP-E (encapsulation) -- інкапсуляція пакетів IPv4 в пакетах IPv6

• MAP-T (translation) -- трансляція пакетів IPv4 у пакети IPv6, за якого адреси IPv4 кодуються у адресах IPv6

Ідея технології MAP полягає у забезпеченні взаємного відображення пакетів між IPv4 та IPv6 незалежно від стану сесії (stateless). Це забезпечує ефективну реалізацію та масштабованість (на відміну, наприклад, від CGN).

Однією з переваг MAP є так звана агрегаційна модель -- використання розширеного поняття адресного простору, в якому у якості адреси фактично використовується комбінація 32-бітової IPv4-адреси та 16-бітового номеру TCP/UDP L4-порта. Неперервний простір, утворений такими адресами здатен бути розподілений між користувацькими пристроями за допомогою принципу, що є еквівалентним CIDR для IPv4.

MAP здійснює відображення, подібне до NAT44, яке, втім, відрізняється від традиційних NAT44 або NAT444. Замість надання блоку публічних IPv4-адрес кожному користувацькому пристрою (NAT) або однієї IPv4-адреси (PAT), використовуються комбінації з IPv4-адрес та діапазонів L4-портів. Тобто, різні користувацькі пристрої можуть використовувати спільну IPv4 адресу та різні діапазони L4-портів. Унікальні комбінації адрес+портів використовуються користувацькими пристроями, які реалізують MAP, для відображення у IPv6-адреси. Алгоритм MAP зберігає можливість призначення виділеної IPv4-адреси або навіть діапазону адрес одному користувацькому пристрою.

Втім, головною перевагою MAP є відсутність необхідності відслідковування стану сесій у трансляціях пакетів, адже процедура полягає лише в однозначному перетворені між комбінаціями IPv4-адрес та портів з одного боку і IPv6-адрес та портів з іншого. Обробка виконується "на лету" з високою продуктивністю, відсутні обмеження у кількості підтримуваних сесій на зразок NAT44 або Dual-stack light (DS-Light).

MAP забезпечує гнучкість топології трас передачі пакетів, зокрема, можлива асиметрія у відображеннях в бік провайдерського MAP-маршрутизатора та від нього. Має місце також краща стійкість (пружність), зокрема, до DDOS атак за рахунок атоматичної зворотньої (reverse) перевірки на предмет підміни джерела.

MAP-T та MAP-E функціонують подібно один до одного, втім, оскільки MAP-E не здійснює інкапсуляції/декапсуляції, він характеризується дещо меншими накладними витратами. До того є й інщі відмінності між MAP-T та MAP-E, пов'язані з підтримкою QoS, ICMP, фрагментації.

MAP являє собою альтернативу до таких технологій співіснування IPv4 та IPv6, як Обмежений Подвійний Стек (Dual-Stack Lite, DS-Lite) та Обмежений транспорт 4поверх6 (Lightweight 4over6). Порівняємо ці технології з MAP. 

DS-Lite. Користувацькі пристрої будують IPv4-поверх-IPv6 тунелі до провайдерського тунельного концентратора, який відомий під назвою Міжпротокольного Перехідного Маршрутизатора (Address-Family Transition Router, AFTR). AFTR контролює стан сесій користувачів та здійснює трансляцію NAT44. Проблемою DS-Lite є підтримка великої кількості тунелів, адже контроль стану сесій вимагає додаткових ресурсів.

Lightweight 4over6. Функціонально подібний до DS-Lite, проте намагається полегшити навантаження на AFTR за рахунок перенесення NAT на користувацькі пристрої. Очевидно, для цього необхідне відповідне забезпечення (provisioning) користувацьких пристроїв зовнішніми IPv4 адресами та діапазонами портів. До того ж AFTR має зберігати відповідність запропонованих користувацьким пристроям IPv4 адрес до IPv6 адрес, які використовують ці пристрої. Метод потребує синхронізації даних між AFTR та системою забезпечення (provisioning system) та не підтримує деякі топології, наприклад, взаємодію між користувачами повз AFTR.

Джерела

1. Mapping of Address and Port Using Translation 
2. Mapping of Address and Port
3. Carrier-grade NAT

MySQL 5.6: додано перевірку контрольних сум даних під час реплікації

Версія 5.6 бази даних MySQL з'явилася вже досить давно. і, гадаю, всі вже обізнані з вдосконаленями, які були впроваджені в цій версії. Зокрема, мене свого часу приємно вразило зростання продуктивності -- швидкість виконання деяких запитів в застосуванні, з яким я працював, зросла у 10-20 разів. Проте, зараз хочу звернутися до іншої доданої функціональності -- використання контрольних сум під час реплікації.

Технологія реплікації в найпростішому випадку передбачає дублювання інформації певного сервера баз даних (майстера) на іншому сервері (слейві). Одне з можливих використань реплікації -- резервне копіювання даних. При цьому важливим є гарантування ідентичності даних на майстері і слейві. На жаль, MySQL 5.6 не дає повної гарантії відповідності даних, проте має певне вдосконалення порівняно з версією 5.5: можливість контроля цілісності бінарних лог-файлів (які є засобом передачі інформації від майстера до слейву) за допомогою контрольних сум. Контрольні суми можуть вираховуватися як на майстері, так і на слейві. У разі пошкодження бінарних логів здійснюється відповідна сигналізація про помилку. Про це стисло і наглядно йдеться в статті Peter Zaitsev "Replication checksums in MySQL 5.6".

До речі, один з наслідків впровадження контрольних сум у реплікації в версії 5.6 -- це порушення сумісності з 5.5. Щойно спостерігав, як перехід з 5.5 до 5.6 на майстері призвів до зупинки слейва, який залишився у версії 5.6:

mysql> show slave status \G...
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
...
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave can not handle replication events with the checksum that master is configured to log; the first event 'mysql-bin.000035' at 834715620, the last event read from './mysql-bin.000037' at 120, the last byte read from './mysql-bin.000037' at 120.'
...

Вочевидь, варто оновлювати версії на майстері і слейві синхронно.

Книга тижня від CiscoPress: Designing Networks and Services for the Cloud

Чергова важлива книга від CiscoPress з 50% знижкою протягом поточного тижня у eBook Deal of the Week.

 Designing Networks and Services for the Cloud

By Sudhir Modali, Muhammad Abid, Huseni Saboowala
Published May 20, 2013 by Cisco Press
Series: Networking Technology
Pages: 336
 

Формати:  EPUB, MOBI, та PDF.

Зміст книги доступен тут.


Важливі теми:

•  Virtualization Basics
•  Server Virtualization
•  Network Virtualization
•  Storage Virtualization
•  Cloud Service Models (SaaS, PaaS, IaaS)
• Deployment Models for the Cloud (public, private, hybrid)

та багато іншого.

Встановлення та оновлення Oracle VirtualBox в Ubuntu

Oracle VirtualBox -- безкоштовний та зручний у використанні гіпервізор для віртуалізації. Проте, встановлення VirtualBox на платформі Ubuntu має певні особливості. Використання стандартного шляху інсталляції пакету за допомогою Центру програмного забезпечення (Software Center) супроводжується помилками та встановлена програма в результаті виявляється непрацездатною. Що треба робити в цій ситуації, описано далі.

Видалити ті елементи VirtualBox, які вже були встановлені. Їх перелік можна отримати так:

dpkg -l '*virtualbox*'

Видаляємо їх всі, наприклад:

dpkg -r virtualbox

Встановити пакет для підтримки динамічних модулів ядра (Dymamic Kernel Modules Support) dkms:

apt-get install dkms

Завантажити актуальну версію VirtualBox, що відповідає версії та архитектурі встановленої у вас операційної системи, зі сторінки https://www.virtualbox.org/wiki/Linux_Downloads, наприклад:

wget http://download.virtualbox.org/virtualbox/4.3.0/virtualbox-4.3_4.3.0-89960~Ubuntu~precise_amd64.deb

Встановити VirtualBox:

dpkg -i  virtualbox-4.3_4.3.0-89960~Ubuntu~precise_amd64.deb

Завантажити пакунок доповнень (Extension Pack) зі сторінки https://www.virtualbox.org/wiki/Downloads:

wget http://download.virtualbox.org/virtualbox/4.3.0/Oracle_VM_VirtualBox_Extension_Pack-4.3.0-89960.vbox-extpack

Запустити VirtualBox:

virtualbox

Обрати в головному меню Файл -- Налаштування... -- Розширення, обрати завантажений файл.

Процедуру встановлення VirtualBox завершено.

У разі, коли потрібно оновити вже встановлену версію VirtualBox на новішу:

dpkg -i virtualbox-4.3_4.3.14-95030~Ubuntu~raring_amd64.deb

Після чого встановити пакунок доповнень (Extension Pack) відповідної версії подібно до того, як описано вище.

Книга тижня від CiscoPress: Data Center Fundamentals

50% знижка на корисну книгу на сайті видавництва CiscoPress.

Data Center Fundamentals

By Maurizio Portolani, Mauricio Arregoces
Published Dec 04, 2012 by Cisco Press
Series: Fundamentals
Pages: 1104


Книжка доступна у форматах EPUB, MOBI, та PDF. При стандартній ціні $66 протягом поточного тижня (eBook Deal of the Week) її можна придбати за $33. Зміст книги можна переглянути тут (оберіть вкладку "Sample Content"). Гадаю, ця книжка буде корисна в першу чергу тим, хто починає знайомитися з технологіями дата-центрів, але також містить цікавий матеріал для досвічених інженерів -- зокрема, технології безпеки, віртуалізація, балансування навантаження. Планую додати її у перелік рекомандованої літератури в своєму майбутньому курсі з технологій дата-центрів.

Синхронізація часу в віртуальних машинах

Є одна проблема з підтримкою точного часу на віртуальних машинах (ВМ).
Все добре, поки ВМ знаходиться в активному стані та за точністю часу на ній слідкує демон ntpd [1]. Проблема виникає тоді, коли сервер-носія має бути перезавантажений, або вимкнений на деякий час. За звичай під час завершення роботи носія всі ВМ, що знаходяться на ньому, переводяться в "сплячий" режим (suspended), під час якого їх поточний стан (повний вміст оперативної пам’яті) зберігається на диску носія. Коли носій завантажується і відновлює свою роботу, ВМ відтворюють свій збережений стан на момент, що передував вимкненню носія (resumed).
Між моментами переходу ВМ у сплячий режим та відновлення їх стану проходить певний час. Але ВМ після відновлення роботи "перебувають у минулому", тобто вважають за поточний той час, в який відбувся перехід до сплячого режиму. Виникає різниця між поточним власним часом ВМ та дійсним поточним часом. Ця різниця дорівнює принаймні часу перезавантаження носія, що для сучасних серверів становить 5-10 хвилин. Різниця може бути і більшою, якщо носій якийсь час був вимкнений.
Відновити точний час на ВМ покликаний  демон ntpd. Проте, якщо різниця перебільшує певне порогове значення (panic threshold), яке типово складає 1000 секунд [2], ntpd аварійно завершить роботу.
Рішенням може стати періодичний контроль наявності на ВМ працюючого демона ntpd, та запуск йогоу разі відсутності. Також доречно контролювати різницю між поточним часом ВМ та дійсним часом. У разі, якщо ця різниця значна (ознакою цього є те, що демон ntpd перебуває в несінхронізованому стані), варто зупинити ntpd, встановити правильний час за допомогою утіліти ntpdate, після чого знову запустити ntpd.
Пропоную вашій увазі нескладний скрипт для Linux (див. нижче), який виконує означені дії. Розмістіть його в каталозі /etc/cron.d для щогодинного запуску.

Джерела:

1. ntpd - Network Time Protocol (NTP) Daemon
2. Manual Reference Pages  - NTP.CONF (5)

---

#!/bin/sh

LOCK="/var/lock/ntpwatch/ntpwatch.lock"

mkdir -p `dirname $LOCK`
(
  if ( ! flock -nx 200 ); then
    echo "Cannot obtain lock (other instance may be running)"
    exit 1
  fi

  if ( ! service ntpd status ); then
    echo "ntpd is not running, starting"
    service ntpdate start
    service ntpd start
  fi

  echo "Waiting up to 300 sec until ntpd is synchronized"
  ( while ! ntpstat;do sleep 5;done ) || sleep 300

) 200>$LOCK
rm -f $LOCK

Поради для починаючих блогерів (звичайно, що не від мене :-))

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

Отже: How do you write a blog post a day? by Ivan Pepelnjak

Налаштування сервера PPTP VPN на маршрутизаторі MikroTik

Днями виникла потреба терміново налаштувати VPN для доступу у віддалену мережу, в якій у якості кордонного маршрутизатора використовується MikroTik RB751G-2HnD (гадаю, що рішення підходить також для використання на інших пристроях з операційною системою RouterOS).

Для налаштування сервера VPN увійдіть у командний рядок маршрутизатора, наприклад, по SSH:

ssh admin@router.remoteoffice.com

Додайте IP-адресу, яка буде використовуватись у VPN-тунелі на боці маршрутизатора:

/ip address add address=10.10.100.1/24 interface=ether2
/ip address print

Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         INTERFACE
 0   ;;; default configuration
     10.10.0.1/24      10.10.0.0      ether2
 1   10.10.1.1/24      10.10.1.0      ether3
 2   10.10.2.1/24      10.10.2.0      ether4
 3   10.10.3.1/24      10.10.3.0      ether5
 4 D 123.123.23.23/22  123.123.23.0   ether1-gateway
 5   10.10.100.1/24    10.10.100.0    ether2

Активуйте сервер PPTP:

/interface pptp-server server set enabled=yes/interface pptp-server server print
 
            enabled: yes
            max-mtu: 1450
            max-mru: 1450
               mrru: disabled
     authentication: mschap1,mschap2
  keepalive-timeout: 30
    default-profile: default-encryption

Створіть профіль для користувача:

/ppp profile add name="admin" local-address=10.10.100.1 remote-address=10.10.100.250 use-encryption=yes
/ppp profile print
 
Flags: * - default
 0 * name="default" remote-ipv6-prefix-pool=none use-ipv6=yes use-mpls=default use-compression=default use-vj-compression=default use-encryption=default only-one=default change-tcp-mss=yes
 1   name="admin" local-address=10.10.100.1 remote-address=10.10.100.250 remote-ipv6-prefix-pool=none use-ipv6=yes use-mpls=default use-compression=default use-vj-compression=default use-encryption=yes only-one=default change-tcp-mss=default
 2 * name="default-encryption" remote-ipv6-prefix-pool=none use-ipv6=yes use-mpls=default use-compression=default use-vj-compression=default use-encryption=yes only-one=default change-tcp-mss=yes

Задайте ім'я та пароль користувача VPN:

/ppp secret add name=vpnuser password=vpnpass service=pptp profile=admin/ppp secret print
 
Flags: X - disabled
 #   NAME     SERVICE CALLER-ID PASSWORD PROFILE REMOTE-ADDRESS
 0   vpnuser  pptp              vpnpass  admin

Відкоригуйте налаштування пакетного фільтру:

/ip firewall filter add chain=input action=accept protocol=udp dst-port=1723 src-address=48.48.48.0/22
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=1723 src-address=48.48.48.0/22
/ip firewall filter print
/ip firewall filter move 7 0
/ip firewall filter move 8 0
/ip firewall filter print
 
Flags: X - disabled, I - invalid, D - dynamic
 0   chain=input action=accept protocol=udp dst-port=1723 src-address=48.48.48.0/22
 1   chain=input action=accept protocol=tcp dst-port=1723 src-address=48.48.48.0/22
 2   ;;; default configuration
     chain=input action=accept protocol=icmp
 3   chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=443
 4   chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=22
 5   ;;; default configuration
     chain=input action=accept connection-state=established
 6   ;;; default configuration
     chain=input action=accept connection-state=related
 7   ;;; default configuration
     chain=input action=drop in-interface=sfp1-gateway
 8   ;;; default configuration
     chain=input action=drop in-interface=ether1-gateway

Сервер VPN готовий, можете з'єднуватися. Для доступу до пристроїв мережі за машрутизатором вам може знадобитися встановити на своєму комп'ютері маршрут для адресного блоку мережі в бік маршрутизатора:

route add 10.10.0.0 mask 255.255.0.0 10.10.100.1

Забезпечення надійності бази даних MySQL у дата-центрі

Зверніть увагу на дві статті, щойно запропоновані на сайті компанії Percona:

• MySQL Backup and Recovery Best Practices by Ryan Lowe
• High Level Multi-Datacenter MySQL High Availability by Jay Janssen

Компанія Percona є розробником системи керування базами даних (СКБД) Percona Server, яка є альтернативою популярній СКБД MySQL, що зараз належить компанії Oracle, та базується на тому самому вихідному коді. Окрім повної сумісності з MySQL СКБД Percona Server має низку корисних розширень та утіліт, які також можуть використовуватись з MySQL.

В статті MySQL Backup and Recovery Best Practices здійснено детальну систематизацію методів створення резервних копій баз даних з метою запобігання втрати даних у разі аварій чи помилок. Статтю High Level Multi-Datacenter MySQL High Availability присвячено заходам для забезпечення високої надійності СКБД, зокрема, за допомогою реплікації. Обидві статті є теоретичними і навряд чи будуть корисні системним адміністраторам, які шукають готових рішень. Натомість ці статті стануть в нагоді аналітикам.

getopts: зручний інструмент для використання в шел-скриптах

Вам доводилося, напевно, створювати нескладні скрипти операційної оболонки Unix/Linux (шел-скрипти), які використовують додаткові опції, вказані у командному рядку. Наприклад:

$ processdata.sh -h

Usage:
processdata.sh [options]

Possible options:
-c <config-file> -- use configuration file
-f -- force conversion
-h -- print usage screen
-v -- be verbose

Забезпечити коректну обробку опцій засобами шелу може бути достатньо складно (адже треба врахувати можливості вказання опцій в довільному порядку, різні варіанти синтаксису, якто -fv або -f -v, та ін.), якщо не користуватися утілітою шела getopts. Ось зразок її використання, гадаю, він не потребує коментарів:

#!/bin/sh

OPTION=""
OPTARG=""

while getopts c:fрv OPTION; do

  case $OPTION in
    c ) CONFIG=$OPTARG;;
    f ) FORCE=1;;
    h ) echo "Usage: $0 [-fhv] [-c <config>]"; exit 0;;
    v ) VERBOSE=1;;
  esac
 
done

echo "CONFIG  = $CONFIG"
echo "FORCE   = $FORCE"
echo "VERBOSE = $VERBOSE"

Нова SQL база даних F1 від Google: назад в майбутнє

Google презентував нову базу даних F1 своєї розробки. Нова база має можливості до масштабування на рівні NoSQL баз, але при цьому забезпечує цілісність (консистентність) даних та наявність SQL інтерфейсу. Фактично, F1 демонструє показники, заради досягнення яких створювалися NoSQL бази, але при цьому є вільною від основних недоліків, притаманних NoSQL базам. F1 функціонує на платформі Spanner, що здійснює розподілення навантаження в глобальній інфраструктурі дата-центрів. Наразі на базу даних F1 переведено сервіс Google AdWords.

Оригінал новини: Google goes back to the future with SQL F1 database. By Jack Clark, 30th August 2013

Вебінар: маршрутизація для окремих хостів (Host Routing)

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

Про компанію Enterasys Networks
Започаткована в 1983 році під назвою Cabletron Systems. Виробник інфраструктурних мережних компонентів, зокрема L2/L3-комутаторів, бездротового обладнання, систем керування. Розробник технологій для хмарних обчислень, SDN, BYOD, та ін.

Про корисну функцію archive при конфігуруванні Cisco

Уявіть, що ви працюєте в групі керування мережею (NOC), яка опікується великим парком з маршрутизаторів та комутаторів Cisco. У вас виникають питання по роботі одного з маршрутизаторів, який до того працював бездоганно. Ви розумієте, що хтось з колег нещодавно редагував конфігурацію (а може то були ви самі, але забули :-). Намагаєтесь швидко зрозуміти, в чому полягають зміни конфігурації, що складається з декількох тисяч рядків. Знайома ситуація?

Інший приклад. Ви відлагоджуєте нову функціональність на маршрутизаторі чи комутаторі. Робите десятки змін конфігурації, але не зберігаєте поточну конфігурацію у флеш, щоб не зіпсувати попередні відпрацьовані налаштування. Нарешті з'являється потреба повернутися до попередньої конфігурації, відкинувши останні зміни. Як це зробити? Варіант з перезавантаженням пристрою виглядає малопривабливо. А якщо ви на автоматі встигли декілька разів ввести write?

Звичайно, в обох випадках можливим рішенням є ретельне документування кожної виконаної дії, таким чином зробити відкат до попереднього стану не становить проблем. Ще краще, якщо в вас налаштовано Command Accounting з використанням сервера TACACS+. Втім є простіший метод: вбудована система відслідковування змін конфігурації Cisco IOS.

Розглянемо фрагмент конфігурації:

RT1.CORE#show running-config | section arc
archive
 log config
  logging enable
  hidekeys
 path flash:$h.cfg
 maximum 14
 write-memory
RT1.CORE#

Налаштування забезпечують зберігання конфігурації у флеш кожного разу під час виконання команди write (або copy running-config startup-config), при чому кожного разу з новим іменем файлу. Загальна кількість збережених конфігурацій -- 14 (за замовченням -- 10). Формат імені файлу конфігурації у флеші: <hostname>.cfg-<num>. Переглянемо перелік збережених конфігурацій:

RT1.CORE#sh arc
The maximum archive configurations allowed is 14.
There are currently 2 archive configurations saved.
The next archive file will be named flash:RT1.CORE.cfg-2
 Archive #  Name
   1        flash:RT1.CORE.cfg-0
   2        flash:RT1.CORE.cfg-1 <- Most Recent
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14

Зміни в конфігурації RT1.CORE.cfg-1 порівняно з RT1.CORE.cfg-0:

RT1.CORE#sh arc conf diff flash:RT1.CORE.cfg-0 flash:RT1.CORE.cfg-1
Contextual Config Diffs:
interface Loopback16329
 +description AS16329

RT1.CORE# 

Зміни в поточній конфігурації, які ще не були збережені у флеш:
 
RT1.CORE#sh arc conf diff flash:RT1.CORE.cfg-0
Contextual Config Diffs:
+ip host google 8.8.8.8
+ipv6 unicast-routing
+ipv6 cef

RT1.CORE#

Більше деталей знайдете на сторінці Configuration Change Notification and Logging.
Зауважте, що після перезавантаження пристрою лічильник збережених конфігурації буде скинутий в 0, але всі збережені раніше конфігурації знаходяться у флеші.

Asus повідомляє про першу у світі материнську плату з інтерфейсами Thunderbolt-2

Два інтерфейси Thunderbolt-2 здатні забезпечити швидкість передачі даних до 20Гбіт/с. Також плата має такі інтерфейси:

• 6 портів USB 3.0
• 4 порти USB 2.0
• вихід HDMI
• 2 інтерфейси GigabitEthernet
• 10 портів SATA III
• вбудований модуль 802.11ac
• вбудований модуль Bluetooth 4.0
• 2 порти PCI Express 3.0

Очікувана ціна плати -- $349.99.

Оригінал статті: Asus is first to the party with a Thunderbolt 2-certified motherboard.

Книга тижня від CiscoPress: Data Center Virtualization Fundamentals

Скористайтеся нагодою придбати на CiscoPress за зниженою ціною важливу книжку. Повна назва:

Data Center Virtualization Fundamentals: Understanding Techniques and Designs for Highly Efficient Data Centers with Cisco Nexus, UCS, MDS, and Beyond

By Gustavo A. A. Santana
Published Jun 20, 2013 by Cisco Press.
Dimensions: 7-3/8" x 9-1/8"
Pages: 900
Edition: 1st




Книжка доступна у форматах EPUB, MOBI, та PDF. При стандартній ціні $51.99 протягом поточного тижня (eBook Deal of the Week) її можна придбати за $25.99, тобто зі знижкою 50%. Для тих, хто не має досвіду купівлі на CiscoPress: куплені книжки зберігаються у вашому акаунті на CiscoPress і доступні до завантаження відразу після сплати. Від часу придбання першої книжки в травні 2011р. я не відчув жодного обмеження стосовно часу зберігання чи кількості разів завантаження.

Зміст книги можна переглянути тут (оберіть вкладку "Sample Content"). Погодьтеся, книга варта того, щоб зайняти своє місце в вашій бібліотеці.

Гіпервізор -- базова платформа для віртуалізації

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

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

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

Прикладами гіпервізора у вигдяді застосування є програмний комплекс VMware vSphere  або більш прості програми Oracle VirtualBox та Parallels. Гіпервізорами у вигляді складової частини операційної системи (ОС) є KVM (Linux), Hyper-V (MS Windows Server). Автономними гіпервізорами є VMware ESXi та Xen.

Розглянуті гіпервізори вирішують завдання повної віртуалізації, коли ОС віртуального комп'ютера ніяким чином не пов'язується з ОС, встановленою на носії. На одному й тому самому носії, наприклад з встановленою ОС Linux, можливе одночасне функціонування віртуальних комп'ютерів з різними ОС, такими як Linux, FreeBSD, MS Windows.

Слід зазначити, що для деяких ОС реалізується також часткова віртуалізація, коли віртуальні комп'ютери частково використовують ОС, встановлену на носії. При певному спрощені та економії ресурсів подібні засоби віртуалізації накладають обмеження. Зокрема, ОС віртуальних комп'ютерів має бути тією самою, що і в носія. Фактично, в ОС носія створюються контейнери, які створюють дещо на зразок низки проекцій ОС носія. Прикладами подібних засобів є OpenVZ в Linux та FreeBSD jails.

Вузько-спеціалізовані промислові системи

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

• Реалізація алгоритму обробки даних, який надає можливість паралельного виконання окремих дій різними обчислювальними компонентами. Наприклад, мова може йти про багатоканальні (векторні) системи, в яких дані, що відносяться до різних каналів можуть оброблятися незалежно і паралельно. Також можлива побудова системи конвеєрної обробки потокових даних, за якої окремі обчислювальні компоненти реалізують різні стадії обробки -- ступені конвеєру. Звичайно, можливі комбінації різних типів паралельної обробки. Перевагою таких систем є надзвичайна здатність до масштабування -- загальна потужність визначається кількістю задіяних обчислювальних компонентів. Див. також Паралельні обчислення, Конвеєр команд, Vectorization (parallel computing), Pipeline (computing).
  
• Кластери, які складаються з множини обчислювальних компонентів, між якими динамічно розподіляються окремі частини загального алгоритму функціювання. Для зовнішніх систем кластер виглядає як єдиний логічний пристрій. За рахунок використання групи компонентів кластер має підвищену продуктивність та відмовостійкість. Див. також Кластер (інформатика), Computer cluster.
  
  
• Імітація систем, які складаються з великої кількості подібних і незалежних компонентів. Наприклад, імітація групи користувачів мережі з метою тестування.

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

Полігон для експериментів

Уявіть собі розробника кросплатформеного застосування, яке має бути здатним виконуватися на різних платформах -- наприклад, Windows, Linux, FreeBSD, тощо. Використання одночасно декількох фізичних комп'ютерів для цієї мети виглядає незручним. Віртуалізація дозволяє  створити всі потрібні платформи на вашому комп'ютері у вигляді віртуальних серверів. Щоправда, ваш комп'ютер має бути достатньо потужним.

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

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

Віддалене робоче місце

Застосуванням віртуалізації, що наразі викликає великий інтерес, є створення інфраструктури віртуальних робочих місць (Virtual Desktop Infrastructure, VDI). Ідея полягає у тому, що замість віртуального сервера ви створюєте віртуальне персональне робоче місце подібно до налаштування звичайної персональної робочої станції. З цією робочою станцією ви працюєте через її графічний інтерфейс, використовуючі протоколи віддаленого доступу на зразок Remote Desktop Protocol (RDP), Virtual Network Computing (VNC) або інші. Використання віддалених віртуальних робочих місць надає низку очевидних переваг:

• Можливість доступу з будь-якої точки у світі при наявності якісного зв'язку через Інтернет з носієм, на якому встановлено віртуальне робоче місце.
• Можливість використання різноманітних платформ у якості клієнта для доступу до віртуального робочого місця. Платформа клієнта може різнитись -- Windows, MacOS, Linux/Unix, тощо. Основна вимога -- наявність програми віддаленого доступу з підтримкою відповідного протоколу.
• Зручність розгортання та підтримки великої кількості віртуальних робочих місць в умовах підприємства.
• Захищеність даних, оскільки їх обробка виконується на віртуальній робочій станції без пересилання на клієнтський пристрій.

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

• Швидкісний зв'язок з віртуальним робочим місцем, адже робота в графічному інтерфейсі пов'язана з пересилкою великих обсягів даних
• Швидкісне відображення (рендерінг) елементів графічного інтерфейсу на пристрої-клієнті

Швидкісний зв'язок через мережу не є проблемою, якщо клієнт територіально знаходиться поруч з віртуальним робочим місцем. Наприклад, користувачі офісу можуть використовувати віртуальні робочі станції, створені на сервері-носії, який розташовано в серверій кімнаті в тому самому офісі. Локальна мережа з пропускною спроможністю 1 Гбіт/с здатна забезпечити достатню швидкість пересилки даних між клієнтами та віртуальними робочими станціями. Швидкість пересилки даних через Інтернет також поступово зростає. Насьогодні цілком реально отримати швидкість передачі даних між сервером та клієнтом (з пересилкою даних здебільше в напрямку до клієнта) до 10 Мбіт/с. Цього достатньо, щоб задовільнити потреби багатьох застосувань.

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

Динамічно створювані віртуальні сервери

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

Як наслідок, отримуємо можливість динамічного регулювання використованих обчислювальниї ресурсів. Така можливість може не бути надто потрібною у випадках, коли потрібна підтримка певного сервісу у режимі 24х7 з приблизно постійним рівнем навантаження. Втім, для задач, які потребують ресурсів для однократного швидкоплинного використання, або для задач, в яких навантаження має неоднорідний вибухоподібний характер, можливість швидкого додавання та вилучення ресурсів є дуже корисною. Наведемо приклади задач, для яких доречним є динамічне регулювання задіяних обчислювальних ресурсів:

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

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

Потреба у використанні хмарних середовищ для вирішення виробничих завдань сучасних підприємств призвела до появи окремого ринку послуг. Насьогодні найбільш відомими постачальниками послуг хмарних обчислень у світі є компанії Amazon, Rackspace, Google, Hewlett Packard. В Україні хмарний сервіс пропонує компанія De-Novo.

Технологія Cisco FabricPath

FabricPath є новітня пропрієтарна технологія другого рівня (Layer 2) від Cisco Systems, яка покликана замінити протоколи STP та PortChannel на рівні розподілення (Distribution). FiberChannel успадкоємлює найкраще з зазначених протоколів -- відсутність контурів, використання сумарної пропускної здатності паралельних каналів, балансування навантаження, органічно інтегрується з VLAN. Технологія проста для конфігурування та супроводу. Насьогодні підтримується комутаторами сімейства Nexus та орієнтується на використанні в дата-центрах.

Посилання за темою:

1. Cisco FabricPath
2. Quick Start Guide :: FabricPath
3. Unified Fabric

До пошуку загубленого пристрою з Android

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

Google повідомив про підготовку застосування під назвою Android Device Manager (ADM), яке надасть можливість відшукати загублений пристрій з Android. Пристрій (за умови, якщо він ввімкнений, звичайно) можна заставити задзвонити або відобразити його місцезнаходження на Google Maps. Якщо віднайти пристрій все ж таки неможливо, власник може віддалено почистити його від особистих даних.

Подібне застосування для iPhone пропонується вже з 2010 р., при чому, воно має додаткову вельми корисну функцію повного блокування пристрою з відображенням лише телефонного номеру власника на екрані. Втім, добрими новинами є те, що ADM буде бескоштовним, та підьримуватися будь-яким пристроєм з Android, починаюси з версії 2.2.

Оригінал новини: Lost phone? Google's got an app for that, coming this month. Free location and remote wipe service for Android devices. By Neil McAllister, 3rd August 2013

Віртуальні мережні інфраструктури

Говорячи про винесення сервісів на віртуальні сервери, ми залишили поза увагою такий суттєвий момент як підключення віртуальних серверів до мережі. Фізичні сервери мали мережні інтерфейси, які з'єднувалися з мережними комутаторами. Під'єднання до мережі віртуальних серверів має певні особистості:

• Віртуальні сервери мають віртуальні мережні інтерфейси. Для їх під'єднання до мережних комутаторів зовні носія ці віртуальні інтерфейси потрібно пов'язати з фізичними інтерфейсами сервера-носія, які вже безпосередньо з'єднуються з комутаторами.
• Для взаємодії віртуальних серверів, що знаходяться на одному носії, не обов'язково пересилати трафік через мережні інтерфейси носія -- цей трафік може бути переданий між інтерфейсами віртуальних серверів.
• Носій виконує роль посередника між віртуальними серверами і зовнішньою мережею. Посередник може бути повністю прозорим для трафіка віртуального сервера, або виконувати функцію IP-маршрутизатора, чи навіть з трансляцією адрес (NAT).

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

Віртуальний маршрутизатор можна уявити як ще один віртуальний сервер з декількома інтерфейсами, функцією якого є маршрутизація пакетів між ціма інтерфейсами. Насправді, рішення з використанням Unix/Linux сервера у якості маршрутизатора, відоме давно. Можливо також використання на віртуальних серверах спеціалізованих операційних систем на зразок Vyatta чи Router OS.

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

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

Статичні віртуальні сервери

Статичні віртуальні сервери виглядають найзрозуміліше. Уявіть, що у вас був традиційний "фізичний" сервер, якій ніс на собі деякі мережні сервіси. Ви замінили цей фізичний сервер на віртуальний, розмістивши його на іншому фізичному сервері, який виконує роль носія. Що це дало:

• На носії ви можете розмістити декілька віртуальних серверів. Низку фізичних серверів, що несли мережні сервіси, замінив єдиний фізичний сервер-носій. Результат -- краще використання простору, електроенергії, обчислювальної потужності. Як слідство -- помітна економія коштів. Можливо, це один з найголовніших аргументів.
• Ви можете замінити один сервер, який ніс багато сервісів (веб, ДНС, пошта, CVS/SVN, тощо) на декілька віртуальних серверів, кожен з яких несе лише один з сервісів. При незначному зростанні накладних витрат ви отримуєте кращу керованість більш простих серверів та надійність, оскільки проблеми, що виникають з кожним окремим сервером не впливають на решту з них. (Насправді, тут можна відчути наближення іншої проблеми -- узгодженого керування великою кількістю віртуальних серверів. Про це обов'язково поговоримо згодом).
• Ви можете створити базовий шаблон для віртуального сервера і у разі потреби створення нового сервера просто клонувати цей шаблон. Це швидше, простіше і надійніше ніж кожного разу інсталювати окремий фізичний сервер.
• Віртуальні сервери можна переносити між носіями. В найпростішому випадку це виглядає як вимкнення сервера на одному носії та ввімкнення на іншому. Також сьогодні вже є технології, які дозволяють перемістити віртуальний сервер на інший носій взагалі без переривання його роботи. Наявність копій віртуального сервера на різних носіях може бути використана для відмовостійкості.
• Зручність розподілу ресурсів між віртуальними серверами -- процесорних ядер, обсягу оперативної пам'яті, дискового простору, мережних інтерфейсів. На сьогодні перерозподіл ресурсів можна здійснівати без зупинки віртуальних серверів.
• Спрощення супроводу систем, адже апаратні проблеми вас турбують лише стосовно декількох носіїв. З огляду на те, що для носіїв, як правило, обирається обладнання найвищого гатунку (наприклад, сервери відомих брендів) , закладається відмовостійкість (масиви RAID) та здатність до масштабування (мережні запам'ятовуючі пристрої), вірогідність апаратних проблем значно знижується порівняно з групою дешевих саморобних фізичних серверів, які масово використовувалися раніше.
• З віртуальними серверами простіше виправляти порушення працездатності. У вас постійно є віддалений доступ до консолі сервера, що дозволяє ефективно вирішувати проблеми під час завантаження або порушення доступності мережі (наприклад, в наслідок помилки під час налаштування захисного фільтру). Аналогічна функціональність для фізичних серверів забезпечується лише за допомогою пристроїв IP-KVM, які досить дорого коштують.
• Віртуальні сервери надають можливість створення миттєвих знімків (snapshot) свого стану. Це корисно під час випробувань або встановлення ризикованих оновлень. Якщо систему буде пошкоджено, ви відновлюєте її сан на момент створення миттєвого знімку.

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

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

• Складність ефективного керування всіма віртуальними системами, якіх стає помітно більше, ніж було фізичних, та їх загал все більше нагадує гомогенну сіру масу, або, радше, хмару (cloud)
• Висока вартість носіїв. Адже тепер, коли 1-2 фізичні сервери виконують функції, які раніше виконували 10-20 віртуальних серверів, вимоги щодо надійності і якості "заліза" стали на порядок вищі. До того ж є пряма вмотивованість придбання якомога потужнішого обладнання, здатного нести на собі більше віртуальних серверів -- в цьому випадку виграш від використання віртуалізації максимальний.

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

З чого почати?

Віртуалізація -- надто широка галузь. З чого почати знайомство? Будь-яку технологію варто розглядати як інструмент, який може бути використаний для вирішення певних задач. Як за звичай буває, технічні задачі передбачають декілька можливих рішень з використанням різних інструментів. Тому ті задачі, які ми вирішуватимемо за допомогою віртуалізації, скоріше за все можуть бути вирішені і інакше. Проте для певних застосувань використання віртуалізації є найоптимальнішим шляхом, в наслідок чого ця технологія наразі отримала таке поширення.

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

• Статичні віртуальні сервери, які несуть на собі певні мережні сервіси
• Віртуальні мережні інфраструктури
• Динамічно створювані віртуальні сервери
• Віддалене робоче місце
• Полігон для експериментів
• Вузько-спеціалізовані промислові системи

Розглянемо всі ці задачі окремо.

Дозвольте привітатися...

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