Рубрика «openstack» - 10

Это второе интервью из нашей серии интервью с руководителями проектов OpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis. Интервью публикуется с купюрами в связи с ограничением длины статьи.

Наше второе интервью – с Монти Тейлором, техническим руководителем проекта непрерывной интеграции OpenStack CI (Continuous Integration).Читать полностью »

Автор: Piotr Siwczak

Недавно я описал, как работает VlanManager и как он обеспечивает масштабируемость сети и изолированность пользователей. Но до настоящего момента я говорил только о сетях с фиксированным IP-адресом, принадлежащих различным пользователям. И хотя по умолчанию экземплярам выделяются фиксированные IP-адреса, они не гарантируют немедленной доступности экземпляров из-за пределов сети (или из других ЦОД). Представьте себе следующий сценарий:Читать полностью »

Мы представляем первое из серии интервью с техническими руководителями проектаOpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis. Интервью публикуется с купюрами в связи с ограничением длины статьи.

Наше первое интервью мы взяли у Марка Макклейна, только что избранного технического руководителя проекта OpenStack Networking (ранее известного как “Quantum”).Читать полностью »

Мы сейчас участвуем в проекте по созданию сервиса, который собирает виртуальную инфраструктуру в облаке. Подобные решения на рынке есть, но я вижу, что нам удалось продвинуться в этом вопросе, пожалуй, чуть дальше других облачных провайдеров. Почему – попытаюсь объяснить на конкретных примерах.

Что из себя представляет типовое облачное решение сегодня? Компания малого или среднего бизнеса арендует у провайдера ресурсы: облачные сервера или VDS/VPS. Потом в ручном режиме создает редко встречающиеся в готовом виде элементы инфраструктуры — VPN, балансировщик, подсеть, роутер, изолированную сеть (VLAN)–и прописывает настройки. Для компаний крупного бизнеса, требующих реализации сложной инфраструктуры, все, как правило, ещё тяжелее: для выполнения определённого комплекса работ требуется обращение в службу поддержки провайдера с заявкой на разработку практически индивидуального проекта инфраструктуры. Понятно, что построение уникальной сложной инфраструктуры без готовых элементов – это долго и дорого.

В итоге – куча сил и времени айтишной команды уходит на организацию облачной инфраструктуры. Хотя использование виртуального сервиса быстрее и дешевле, чем организация физической инфраструктуры.

Как собрать из конструктора облачную инфраструктуру

Читать полностью »

Автор: Piotr Siwczak

В первой части статьи я описал основной режим работы сети в OpenStack, в частности сетевого менеджера FlatManager и его дополнение, FlatDHCPManager. В этой статье я поговорю о VlanManager. В то время как менеджеры, работающие в плоском режиме, разработаны для простых и небольших по размеру развертываний, VlanManager подходит для крупных внутренних облаков и публичных облаков. Как предполагает имя, VlanManager полагается на использование виртуальных локальных сетей (“виртуальных LAN”). Назначение виртуальных локальных сетей состоит в разделении физической сети на отдельные широковещательные домены (таким образом, что группы узлов в разных виртуальных сетях не видят друг друга). VlanManager пытается исправить два основных недостатка сетевых менеджеров, а именно:Читать полностью »

Автор: 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. Более подробно о проекте рассказывает мой коллега Дмитрий Мещеряков в видео ниже.Читать полностью »

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

Прошлой осенью в блоге команды 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