Метка «мирантис» - 2

Автор: Piotr Siwczak

За последнее время сети в OpenStack прошли эволюцию от простой, едва ли пригодной к использованию модели к более совершенной с возможностью полной изоляции владельцев. Поддержка различных требований пользователей в OpenStack реализована с помощью т.н. “сетевых менеджеров”. Сетевой менеджер определяет сетевую топологию конкретного деплоймента OpenStack. Начиная с версии Essex, пользователь может выбрать один из трех вариантов сетевых менеджеров: FlatManager, FlatDHCPManager, VlanManager. В этой части статьи мы рассмотрим первые два, для последнего будет отведена вторая часть.

У менеджеров FlatManager и FlatDHCPManager есть много общего. Оба они основываются на концепции сетевых мостов (bridged networking) с использованием одного моста. В качестве примера рассмотрим сеть, состоящую из нескольких узлов.Читать полностью »

Автор: Александр Кузнецов

Проект Hadoop – это широко используемая платформа для распределенных вычислений на основе парадигмы MapReduce. В этой статье я рассмотрю сценарии перемещения двух основных компонентов Hadoop в облако OpenStack — инфраструктуры MapReduce и файловой системы HDFS (Hadoop Distributed File System — распределенная файловая система Hadoop). Прототипом названия проекта Savanna стали африканские равнины, по которым перемещаются слоны, изображенные на логотипе Hadoop. Более подробно о проекте рассказывает мой коллега Дмитрий Мещеряков в видео ниже.Читать полностью »

Автор: Piotr Siwczak
Последняя статья Олега Гельбуха дала обзор различных аспектов бесперебойности в OpenStack. Все компоненты OpenStack разработаны с учетом бесперебойности, но платформа использует и внешние ресурсы, как, например, базу данных и систему обмена сообщениями. И это забота пользователя — развернуть эти внешние ресурсы для безотказной работы.

Очень важно помнить, что все ресурсы с фиксацией состояния в OpenStack используют систему обмена сообщениями и базу данных, а все остальные компоненты не хранят информацию о состоянии (за исключением Glance). База данных и система обмена сообщениями являются ключевыми для платформы OpenStack. В то время как система управления очередью позволяет нескольким компонентам обмениваться сообщениями, база данных хранит состояние кластера. Обе эти системы принимают участие в каждом запросе пользователя, как при отображении списка виртуальных объектов, так и при создании новой виртуальной машины.

По умолчанию для обмена сообщениями используется RabbitMQ, а база данных по умолчанию — MySQL. В отрасли известны надежные решения и по нашему опыту их достаточно для масштабирования даже в крупных установках. В теории подойдет любая база данных, поддерживающая SQLAlchemy, но большинство пользователей пользуются базой данных по умолчанию. Для обмена сообщениями трудно найти альтернативу RabbitMQ, хотя некоторые пользуются драйвером ZeroMQ для OpenStack.

Как в OpenStack работают сообщения и база данных

Давайте для начала рассмотрим, как база данных и система обмена сообщениями вместе работают в OpenStack. Для начала я опишу поток данных при наиболее популярном запросе пользователя: создание экземпляра виртуальной машины.

Пользователь отправляет свой запрос в OpenStack, взаимодействуя с компонентом nova-api. Nova-api обрабатывает запрос на создание экземпляра, вызывая функцию create_instance из API-интерфейса nova-compute. Функция делает следующее:Читать полностью »

Автор: Олег Гельбух

Прошлой осенью в блоге команды SwiftStack появился интересный обзор их подхода к созданию мультирегиональных кластеров Объектного хранилища OpenStack (кодовое название проекта — Swift). Этот подход хорошо сочетается со схемой географически распределенного кластера Swift с сокращенным числом реплик (3+1 вместо 3+3, например), над которой мы совместно работали с компанией Webex примерно в это же время. Я хотел бы кратко описать наш подход и остановиться на плане внедрения и предлагаемых изменениях кода Swift.

Текущее состояние OpenStack Swift


Я хотел бы начать с краткого обзора текущих алгоритмов Swift, чтобы затем пояснить, что именно требуется сделать, чтобы создать кластер из нескольких географически разделенных регионов.Читать полностью »

Автор: Дмитрий Уков

Обзор

Многие люди путают объектно-ориентированное хранение с блочным хранением, например, на основе iSCSI или FibreChannel (Storage Area Network, SAN), хотя на самом деле существует много различий между ними. В то время как в сети SAN система видит только блочные устройства (хороший пример имени устройства -/dev/sdb linux), доступ к хранилищу объектов можно получить только с помощью специализированного клиентского приложения (например, клиентского приложения box.com).

Блочное хранилище представляет собой важную часть инфраструктуры облака. Основными способами его использования являются хранение образов виртуальных машин или хранение файлов пользователя (например, резервных копий разных видов, документов, изображений). Основным преимуществом объектного хранения является очень низкая стоимость реализации по сравнению с хранилищем корпоративного уровня, одновременно с обеспечением масштабируемости и избыточности данных. Существует два наиболее распространенных способа реализации объектного хранилища. В этой статье мы сравним два способа, интерфейс к которым предоставляет OpenStack.

OpenStack Swift

Архитектура сети Swift

Объектное хранилище OpenStack (Swift) предоставляет масштабируемое распределенное объектное хранилище с резервированием, которое использует кластеры стандартизированных серверов. Под “распределением” понимается, что каждый фрагмент данных реплицируется по кластеру узлов хранения. Число реплик можно настроить, но оно должно составлять не менее трех для коммерческих инфраструктур.

Доступ к объектам в Swift осуществляется по интерфейсу REST. Эти объекты можно хранить, получать или обновлять по требованию. Хранилище объектов можно с легкостью распределить по большому числу серверов.

Путь доступа к каждому объекту состоит из трех элементов:Читать полностью »

Автор: Piotr Siwczak

Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).

Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.

В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js