Показ дописів із міткою Хмари. Показати всі дописи
Показ дописів із міткою Хмари. Показати всі дописи

субота, 3 травня 2025 р.

Свіжі "скромні колекції" з humblebundle.com, зауважте

 Зверніть увагу, чергові цікаві "скромні колекції": 

  • комплект O'Reilly DevOps 2025 з 15 книжок видавництва O'Reilly  по технологіям DevOps, в який зокрема увійшли бестселери:
    • Terraform Up and Running (3rd edition)
    • Ansible Up and Running (3rd edition)
    • Certified Kubernetes Administrator (CKA) Study Guide
  • комплект Networking Mastery з 20 книжок видавництва <packt> по мережевим технологіям, в який увійшли такі цікаві книжки як:
    • Segment Routing in MPLS Networks
    • Zabbix7
    • AWS Certified Advanced Networking -- Specialty (ANS-C01) Certification Guide
  • комплект AI: Trust, Risk and Security з 10 потужних книжок видавництва Pearson про безпеку в сфері штучного інтелекту
  • комплект навчальних матеріалів Machine Learning Projects for Beginners з 19 відеокерівництв по машинному навчанню (Machine Learning), обробці природніх мов (Natural Language Processing), використання Python. Як свідчить назва, матеріали можуть стати "кік-стартером" для початківців в сфері штучного інтелекту

четвер, 10 квітня 2025 р.

Свіжа "скромна колекція" з humblebundle.com, зауважте

Зверніть увагу, чергова цікава "скромна колекція" комплект з 16 навчальних відеоматеріалів по мережевим технологіям і безпеці та для підготовки до відповідних сертифікацій Cisco, RedHat, AWS: https://www.humblebundle.com/books/networking-and-security-cert-prep-pearson-it-certification-exam-cram-books. Матеріали орієнтовані на початківців. 

понеділок, 7 квітня 2025 р.

Лабораторна робота 8. Знайомство з Kubernetes

Kubernetes – є ефективною платформою оркестрації для програмних систем на основі контейнерів.

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

Особливістю Kubernetes є застосування концепції просторів імен (namespaces), завдяки якій на одному кластері є могливість незалежного розгортання будь-якої кількості застосувань, кожне в індивідуальному просторі імен. Наявність програмних інтерфейсів – API, для керування всіма компонентів Kubernetes створює умови для інтеграції з зовнішніми системами, зокрема системами керування, моніторингу, безпеки, а також надає можливість розширення функціональності Kubernetes шляхом додавання компонентів, інтегрованих в інфраструктуру Kubernetes.

Базовим принципом розгортання і керування застосуваннями в Kubernetes є декларативне управління. Створення або зміна будь-якого обʼєкта в системі здійснюється за допомогою застосування декларацій (або маніфестів) – специфікацій кожного обʼєкта, які визначають бажану конфігурацію і стан цих обʼєктів.

Для автоматизації складного процесу розгортання програмних систем в Kubernetes широко використовується менеджер пакунків (так званих чартів) helm.

Docker Desktop – інструментарій керування Docker контейнерами на персональному компʼютері, який також реалізує обмежений функціонал Kubernetes.

субота, 29 березня 2025 р.

Свіжі "скромні колекції" з humblebundle.com, зауважте

 Зверніть увагу, чергові цікаві "скромні колекції": 

неділя, 12 квітня 2020 р.

AWS CLI v2 в Docker-контейнері

AWS запропонувало нову версію свого інтерпретатора команд для CLI у вигляді Docker-контейнера. Це спрощує процедуру встановлення та оновлення AWS CLI, єдине, що вам потрібне, це Docker. Щоправда, також не завадить трішки "хімії" щоб зробити користування зручним. Розберемося детальніше.

Важаємо, що Docker в вас вже встановлений. Якщо ні, існують доволі прості рекомендації щодо того, як його встановити.

$ docker -v
Docker version 19.03.8, build afacb8b

Для встановлення Docker-образу AWS CLI достатньо виконати будь-яку команду, яка потребує запуску контейнера з цього образу (абсолютно подібно до відомої вправи з запуску контейнера hello-world):

$ docker run --rm -it amazon/aws-cli --version
Unable to find image 'amazon/aws-cli:latest' locally
latest: Pulling from amazon/aws-cli
a8d577519c9f: Pull complete
566688c06207: Pull complete
ca757f738665: Pull complete
20a1a6491248: Pull complete
eee974bddccb: Pull complete
Digest: sha256:30119932960947db22fcbabf465c4974134cc30c2c6dc2936694befd55b6ae99
Status: Downloaded newer image for amazon/aws-cli:latest
aws-cli/2.0.7 Python/3.7.3 Linux/4.19.76-linuxkit botocore/2.0.0dev11

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

$ docker images
REPOSITORY     TAG    IMAGE ID     CREATED    SIZE
amazon/aws-cli latest 886e608c1999 5 days ago 287MB

Повторне виконання команди відображення версії:

$ docker run --rm -it amazon/aws-cli --version
aws-cli/2.0.7 Python/3.7.3 Linux/4.19.76-linuxkit botocore/2.0.0dev11

Повністю подібно до виконання аналогічної команди aws попередньої версії:

$ aws --version
aws-cli/1.17.9 Python/2.7.16 Darwin/18.7.0 botocore/1.14.9

Все, що залишається, це зробити використання контейнеризованого AWS CLI більш зручним. Для цього, наприклад, створюємо синонім (alias) в оболонці bash:

$ alias aws='docker run --rm -ti -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

В команді, якій надається синонім "aws", додатково передбачено монтування теки .aws з домашнього каталогу -- для викоритання інформації про обліковий запис AWS поточного користувача, а також відбувається монтування поточної теки для того, щоб було можливо здійснювати копіювання файлів між локальною файловою системою і, наприклад, сховищами Amazon S3:

$ aws --version
aws-cli/2.0.7 Python/3.7.3 Linux/4.19.76-linuxkit botocore/2.0.0dev11

$ echo "hello-bucket" > hello-bucket

$ aws s3 cp hello-bucket s3://bucket20200412




Оригінальна новина: AWS CLI v2 Docker image

середа, 1 квітня 2020 р.

Книги по Azure: акція на https://www.humblebundle.com/

Добра новина для тих, хто цікавиться технологією хмарних обчислень на платформі Azure. В магазині Huble Bundle розпродаж книжок. Три варіанти комплектів -- від $1.00 до $15.00. Акція діятиме до 20 квітня.

понеділок, 2 квітня 2018 р.

Нові сервери DNS для публічного використання: 1.1.1.1 та 1.0.0.1

На додаток до вже звичних публічних серверів DNS 8.8.8.8 та 8.8.4.4 компанії Google в нас з'явилися сервери 1.1.1.1 та 1.0.0.1 від компанії Cloudflare. Принцип роботи -- той самий anycast. Заявлено, що нові сервери будуть найшвидшими серед публічних. Спробував перевірити. Спочатку Google:

Inspiron ~ time host www.dnipro.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

www.dnipro.net has address 5.189.168.209
www.dnipro.net has IPv6 address 2a02:c207:2005:8501::1

real 0m0,426s
user 0m0,006s
sys 0m0,010s

Inspiron ~ time host www.dnipro.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

www.dnipro.net has address 5.189.168.209
www.dnipro.net has IPv6 address 2a02:c207:2005:8501::1

real 0m0,346s
user 0m0,014s
sys 0m0,005s

На другому запиті інформація гарантовано береться з кешу, отже затримка відклику повинна бути найменшою. Як результат, маємо 346 мс. Пробуємо Cloudflare:

Inspiron ~ time host www.dnipro.net 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.dnipro.net has address 5.189.168.209
www.dnipro.net has IPv6 address 2a02:c207:2005:8501::1

real 0m1,316s
user 0m0,013s
sys 0m0,026s

Inspiron ~ time host www.dnipro.net 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.dnipro.net has address 5.189.168.209
www.dnipro.net has IPv6 address 2a02:c207:2005:8501::1

real 0m0,065s
user 0m0,007s
sys 0m0,010s

Отже, затримка дійсно вдвічі менша -- 65 мс.

Зазначений блог-допис також містить багато цікавих посилань:
Як сервери від Google, так і нові сервери від Cloudflare мають IPv6 версії:
  • 8.8.8.8 -- 2001:4860:4860::8888
  • 8.8.4.4 -- 2001:4860:4860::8844
  • 1.1.1.1 -- 2606:4700:4700::1111
  • 1.0.0.1 -- 2606:4700:4700::1001
На додаток після того, як допис вже був опублікований, ще один публічний сервер DNS: 9.9.9.9. Додатково блокує видачу адрес з неблагонадійних сайтів. Швидкість відклику подібна до інших публічних серверів DNS. Не побачив інформації щодо IPv6.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  • Linux Containers and the Future Cloud. By Rami Rosen
  • Docker
  • Open Container Initiative
  • вівторок, 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-скрипти не відповідають належному рівню автоматизації для хмар.
    • Делегування функцій керування користувачам
    В випадках, коли провайдер надає свої ресурси для створення приватних хмар користувачів, доцільно надати можливості і повноваження користувачам для керування своїми хмарними ресурсами. Виконання технологічних операцій в приватній хмарі виконавцями провайдера за запитами від користувача не забезпечує належний рівень оперативності та гнучкості керування. Користувачі повинні мати якомога більші функції для керування своїми хмарами, але не мати вплив на ресурси інших користувачів або провайдера. Вочевидь, при делегуванні функцій керування постає питання про наявність відповідної кваліфікації користувача, аби використанням наданих функцій керування не зашкодити самому собі. Одним зі шляхів приведення у відповідність складності вирішуваних задач і кваліфікації виконавця є високий рівень автоматизації, завдяки якому складні операції здатен виконувати користувач обмеженної кваліфікації.
    • Масштабованість
    Здатність швидкого збільшення обсягу задіяних технологічних ресурсів без зміни впроваджених технологічних процесів. Фактично, мова йде про нарощування потужності шляхом додавання однотипних апаратних компонент -- серверів та комутаторів, які з’єднуються з загальною інфраструктурою по стандартним схемам підключення зі стандартними налаштуваннями. Можливо впровадження автоматичної масштабованості, за якої апаратні компоненти, що перебувають у резерві, автоматично долучаються до використання, та навпаки, звільнені від використання знов переводяться у резерв.
    • Створення віртуальних мереж
    Хмари надають платформу для віртуальних мереж. Необхідність створення віртуальних мереж є важливим фактором для переходу до хмари. Доречно, щоб всі раніше зазначені ознаки --  гнучкий профіль завантаження, швидкість забезпечення, автоматизація, делегування функцій керування та масштабованість в рівній мірі стосувалися компонентів віртуальних мереж, створених у хмарі.

    Посилання:

    понеділок, 8 грудня 2014 р.

    Контролери 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

    Джерело:

    середа, 1 жовтня 2014 р.

    Друга версія OpenDaylight -- 'Helium'

    Вийшла друга знакова версія (milestone) OpenDaylight -- контролера програмно визначених мереж (Software Defined Networking, SDN). Нова версія отримала назву 'Helium'.

    Система OpenDaylight з'явилася як результат спільних зусиль декількох компаній-постачальників мережевих рішень зі створення відкритої платформи для SDN.

    OpenDaylight 'Helium' реалізує контейнер Apache Karaf, краще інтегрований з середовищем OpenStack та з проектом інтеграції баз даних віртуальних комутаторів OpenVSwitch.Появлення OpenDaylight 'Helium' передує виходу нової версії OpenStack 'Juno', яку заплановано на жовтень 2014 р.

    В новій версії підтримується функціональність груп безпеки (security groups) OpenStack, розподілені віртуальні маршрутизатори, балансування навантаження як послуга (load balancing as-a-service). Додано нові протоколи -- OpenFlow Table Type Patterns та PacketCable multimedia. Покращено підтримку кластерізації для відмовостійкості, функції безпеки та авторизації. Впроваджено нову інфраструктуру безпечного завантаження мереж (Secure Network Bootstrapping Infrastructure, SNBI), яка дозволяє користувачам визначати та завантажувати захищені набори контролерів та мережних пристроїв. Під SDN-інтерфейсом (SDNi) впроваджено крос-контролерну конфедерацію з використанням BGP.

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

    Посилання:

    четвер, 25 вересня 2014 р.

    HP створює магазин продуктів для SDN

    Відкриття магазину HP SDN App Store заплановано на 1 жовтня ц.р. В магазині будуть представлені продукти, оптимізовані для використання в першу чергу на платформі SDN, що просувається HP (включає SDN контролер, супутнє програмне забезпечення, підтримувані пристрої), втім можуть використовуватися і на інших платформах.

    Продукти в HP SDN App Store можна виділити в такі категорії:
    • The HP Circle -- продукти, створені і випробувані виключно HP
    • The Premium Circle -- продукти від найбільших постачальників, відтестовані сумісно HP та її партнерами
    • The Partner Circle -- продукти, випробувані власнотужки партнерами HP, та переглянуті HP
    • The Community Circle -- продукти, що знаходяться у вільному доступі та підтримуються спільнотою, які демонструють доказ концепції (proof of concept) та мають відкритий вихідний код.
    Вже відомо, що початково в HP SDN App Store будуть представлені два продукти HP -- Network Optimizer (оптимізація функціювання Microsoft Lync) та  Network Protector для захисту в умовах BYOD.Також будуть представлені шість продуктів від партнерів HP -- BlueCat DNS Director, Ecode evolve, F5 BIG DDoS Umbrella, GuardiCore Defense Suite, KEMP Adaptive Load Balancer Application, та Real Status Hyperglance.

    Джерела:

    середа, 24 вересня 2014 р.

    Brocade оголосила підтримку SDN контролера OpenDayLight в маршрутизаторах Vyatta

    Днями компанія Brocade повідомила про свій новий продукт -- SDN контролер Brocade Vyatta Controller, який базується на проекті з відкритим кодом OpenDayLight. Такий крок здійснюється з метою подальшого розвитку відкритої мережевої платформи. Стверджується, що в новому продукті будуть відсутні "фірмові" доповнення порівняно з OpenDayLight. Заявлено, що  контролер Brocade Vyatta Controller буде підтримуватися маршутизаторами Vyatta.

    Посилання:

    вівторок, 26 серпня 2014 р.

    Безпека даних в хмарі

    За мотивами публікації Combining the Flexibility of Public-Cloud Apps with the Security of Private-Cloud Data.

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

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

    Криптування даних під час зберігання

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

    Закриптовані дані динамічно розкриптовуються під час звернення до них застосування. Таким чином, користувач має змогу оперувати некриптованими даними, в той час, як ресурсам хмари, на яких зберігаються дані, некриптовані дані недоступні.

    Збереження даних у приватних хмарах

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

    Керування ключами

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

    Збереження функціональності застосувань

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

    Також слід зазначити втрату можливості обробки даних фоновими (back-end) застосуваннями хмари.Зарадити проблемі можна, наприклад, шляхом криптування лише деяких полів в базах даних.

    Розміщення

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