Нова 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.

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