Openstack. Детективна історія або куди пропадає зв'язок? Частина перша

Ця історія про OpenStack + KVM. Все почалося, коли все працювало добре. «Стара» платформа всіх задовольняла. Її піднімали без нас, і вона злегка застаріла. Це була Juno. При цьому вона працювала.

В принципі вона була тестової, поки в один прекрасний день не стала бойовою. Ми знати не знали проблем, з якими зіткнулися потім. Начальство, радісно потираючи руки, вирішило оновити парк систем. В тому числі і тестову платформу OpenStack.

Читати далі →

Продуктивність мережі малої латентності InfiniBand на віртуальному кластері HPC HUB

areas
Моделювання складних фізичних процесів в наші дні розглядається як важлива технологічна можливість багатьма сучасними компаніями. Широко використовуваним зараз підходом для створення обчислювачів, здатних розраховувати складні моделі, є створення кластерних систем, де обчислювальний вузол являє собою сервер загального призначення, підключений до мережі малої латентності і керований своєї власної ОС (як правило, з сімейства GNU/Linux).

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

Підтримка мережі малої латентності виртуализационными рішеннями являє собою окрему складну проблему. Для прикладних програм, в більшості випадків сучасна віртуалізація на основі KVM призводить до мінімальних втрат обчислювальної потужності (<1%). Однак спеціалізовані тести мереж малої латентності показують накладні витрати від віртуалізації не більше 20% на операції синхронізації.

Читати далі →

Короткий огляд гібридних хмар на OpenStack і труднощів їх побудови

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



Читати далі →

VZ7 vs VZ6: є привід оновлюватися?

У році вийшла нова версія нашого основного продукту – системи віртуалізації Virtuozzo. З тих пір ми постійно отримуємо запитання: «чи Варто оновлюватися?», «Чим 7ка краще 6ки?» і так далі. Тому на святах виникло бажання розставити крапки над i і в одному пості розповісти про відмінності Virtuozzo останньої версії від попередніх.

image


Читати далі →

Налаштування SPICE-консолі віртуальних машин в OpenStack

Ця стаття буде цікава адміністраторам хмарної платформи OpenStack. Мова піде про відображення консолі віртуальних машин в дашборде. Справа в тому, що за замовчуванням в OpenStack використовується noVNC консоль, яка з прийнятною швидкістю працює в рамках локальної мережі, але погано підходить для роботи з виртуалками, запущеними у віддаленому датацентрі. У цьому випадку чуйність консолі, м'яко кажучи, пригнічує.
У даній статті мова піде про те, як налаштувати в своїй інсталяції Опенстека набагато більш швидку SPICE-консоль.

Читати далі →

Історія одного бага (#1653967)

Abstract: Реальна історія з життя реальних адміністраторів по вилову ідіотського бага.
Повчальна частина: Ніколи недооценивай залежності залежностей.

Вступ
Рядовий апгрейд в лабораторії з Openstack Mitaka до Openstack Newton (нова версія). Кілька deprecated options у файлах конфігурації, keystone переїхав з eventlet на WSGI і поламав існуючу конфігурацію з haproxy; типового «ipv6 listen» apache не почав конфліктувати з haproxy за однакові використовувані порти на зірці (один слухав ipv6, інший ipv4 only), так що запити йшли в haproxy замість апача, де вмирали з 503, т. к. апстрима не було… Втім, історія не про це.

Після того, як основні проблеми були пофишкены, Nova (одна з компонент Openstack) при запуску почала падати з помилкою:
ConfigFileValueError: Value for option url is not valid: invalid URI: 'http://neutron-server.example.com:21345'.
. Це було дуже дивно. З урахуванням, що в конфіги змінилося 100500 опцій, виникла підозра, що ми використовуємо застарілу опцію, яку більше не треба використовувати. Однак, документація говорила, що приклад опції —
url = http://controller:9696
.

Налагодження
Очевидні кроки відладки:
  • Закоментувати опцію — не падає
  • Повторити опцію приклад — не падає
  • Замінити в опції порт на «наш» — можливо, не можна використовувати надто великий номер порту — не падає
  • Замінити в опції url на наш падає
  • Повернути «controller» на місце — не падає
  • Підозра: чи не вміє fqdn: замінити controller на controller.dns — не падає
  • Підозра: занадто багато точок (у нас в реальному коді було 8 точок в url) — controller.dns1.dns2.dns3.dns4 — не падає
  • Залишити з нашого імені лише першу частину:
    http://neutron-server:9696
    — падає! гіпотеза вже зрозуміла.
  • Проверка1:
    http://neutronserver:9696
    — не падає
  • Проверка2:
    http://with-dashes:9696
    — падає!

Читати далі →

Створення розділяється сховища на базі CEPH RBD і GFS2

Більшість кластерних систем передбачає наявність файлової системи доступної зі всіх вузлів кластера. Ця файлова система використовується для зберігання, даних, для організації роботи деяких кластерних підсистем і т. д. Вимоги на продуктивність такої FS можуть сильно відрізнятися для різних завдань, однак, чим вона вище, тим вважається, що кластер більш стійкий і універсальний. NFS сервер на майстер-сайті є мінімальним варіантом такої FS. Для великих кластерів NFS доповнюється розгортанням LustreFS — високопродуктивної спеціалізованої розподіленої файлової системи, що використовує декілька серверів в якості сховища файлів і кілька метаинформационных серверів. Однак така конфігурація володіє рядом властивостей, які ускладнюють роботу з нею у разі, коли клієнти використовують незалежні віртуалізовані кластера. В системі HPC HUB vSC для створення поділюваної FS використовується широко відоме рішення CEPH і файлова система GFS2.
main

Читати далі →

Віртуальний суперкомп'ютер на вимогу

Віртуальний суперкомп'ютер (vSC) — це сучасна альтернатива використанню власних суперкомп'ютерних потужностей для наукомісткого бізнесу і наукових груп при вирішенні ресурсномістких завдань. У процесі бурхливого розвитку хмарних технологій клаудизация почала проникати в найбільш складні IT-сфери — суперкомпьютинг та розподілені обчислення. Один з можливих підходів до задачі клаудизации HPC реалізований компанією HPC HUB.

КДПВ

Читати далі →

Монетизація OpenStack. Від приватного хмари до готового бізнесу за 72 години

Компанія «ПрайсПлан» випустила інтегроване рішення для монетизації хмари під управлінням OpenStack. Рішення призначене відразу для двох сегментів ринку:

  • IT відділи компаній, що управляють ресурсами приватного хмари
  • IaaS провайдери, які працюють на відкритому ринку.

Читати далі →

Mirantis Unlocked validation program. Частина 2: Hard and Soft

Автори: Євгенія Шумахер, Ілля Стечкин

Представляємо вашій увазі другий матеріал, присвячений програмам валідації, які пропонує Mirantis своїм партнерам. минулому пості ми розповідали про те, кому і для чого потрібно валідувати fuel-плагіни. Сьогодні поговоримо про валідації додатків і «заліза».
Читати далі →