Это интервью – третье из серии наших интервью с техническими руководителями проектов OpenStack, размещённое в блоге Мирантис. Нашей целью является просвещение компьютерного сообщества в вопросах, связанных с проектом OpenStack. Ответы на эти вопросы предоставляет сам опрашиваемый. Интервью публикуется с купюрами в связи с ограничением длины статьи.
Итак, это интервью с Джоном Гриффитом, техническим руководителем проекта OpenStack Cinder.Читать полностью »
Рубрика «мирантис» - 3
Интервью с Джоном Гриффитом, руководителем проекта OpenStack Cinder (блочное хранение данных)
2013-07-11 в 19:45, admin, рубрики: api, cinder, cloud, grizzly, LVM, open source, openstack, ptl, python, SATA, solidfire, wiki page, Блог компании Mirantis/OpenStack, мирантисХранение объектов для облака OpenStack: сравнение Swift и Ceph
2013-04-15 в 4:52, admin, рубрики: ceph, crush, open source, openstack, swift, Блог компании Mirantis/OpenStack, мирантис, метки: ceph, crush, open source, openstack, swift, мирантисАвтор: Дмитрий Уков
Обзор
Многие люди путают объектно-ориентированное хранение с блочным хранением, например, на основе iSCSI или FibreChannel (Storage Area Network, SAN), хотя на самом деле существует много различий между ними. В то время как в сети SAN система видит только блочные устройства (хороший пример имени устройства -/dev/sdb linux), доступ к хранилищу объектов можно получить только с помощью специализированного клиентского приложения (например, клиентского приложения box.com).
Блочное хранилище представляет собой важную часть инфраструктуры облака. Основными способами его использования являются хранение образов виртуальных машин или хранение файлов пользователя (например, резервных копий разных видов, документов, изображений). Основным преимуществом объектного хранения является очень низкая стоимость реализации по сравнению с хранилищем корпоративного уровня, одновременно с обеспечением масштабируемости и избыточности данных. Существует два наиболее распространенных способа реализации объектного хранилища. В этой статье мы сравним два способа, интерфейс к которым предоставляет OpenStack.
OpenStack Swift
Архитектура сети Swift
Объектное хранилище OpenStack (Swift) предоставляет масштабируемое распределенное объектное хранилище с резервированием, которое использует кластеры стандартизированных серверов. Под “распределением” понимается, что каждый фрагмент данных реплицируется по кластеру узлов хранения. Число реплик можно настроить, но оно должно составлять не менее трех для коммерческих инфраструктур.
Доступ к объектам в Swift осуществляется по интерфейсу REST. Эти объекты можно хранить, получать или обновлять по требованию. Хранилище объектов можно с легкостью распределить по большому числу серверов.
Путь доступа к каждому объекту состоит из трех элементов:Читать полностью »
Обеспечение бесперебойности (HA) с платформой OpenStack: варианты топологий
2013-04-08 в 8:19, admin, рубрики: api, glance, iscsi, keystone, mysql, open source, openstack, RabbitMQ, Блог компании Mirantis/OpenStack, мирантис, метки: api, glance, iscsi, keystone, mysql, openstack, RabbitMQ, мирантисАвтор: 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 должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:Читать полностью »