Рубрика «glance»

В этой статье я отклонюсь от традиционной для меня темы систем хранения FAS и подниму тему объектного хранения данных в системах NetApp StorageGrid WebScale. Если кратко, то объектное хранение — это третий тип хранения наряду с NAS и SAN. Представьте себе, что каждый файл состоит из данных и метаинформации (владелец, права, время модификации и т.д.), так вот объектное хранение позволяет разъединить эти части и хранить их в виде «ключ/значение». Такой подход хранения информации открывает возможности децентрализованного, распределённого хранения данных огромных масштабов с прозрачной миграцией данных, репликацией и прозрачным переключением конечных потребителей между нодами объектного кластера. В широком смысле объектное хранилище может быть реализовано как на уровне устройства (жесткого диска), при помощи специализированных SCSI команд (Object-based Storage Device Commands), так и на уровне протокола доступа к системе хранения, которая состоит из нескольких дисков (которые, в свою очередь, вовсе не обязаны быть объектными). В обоих случаях используется Ethernet для подключения и IP протокол для передачи данных. Примером реализации объектного хранилища на уровне устройства являются жесткие диски линейки Seagate Kinetic Open Storage platform. Примером систем хранения данных в облаке может быть Microsoft Azure BLOB, Amazon S3. В этой статье я остановлюсь на объектных СХД, которые можно развернуть у себя на сайте и при необходимости подключить к облаку.
Объектное хранилище NetApp StorageGrid - 1
Читать полностью »

Авторы: Николай Марков, Илья Стечкин, Ирина Поволоцкая

Неудержимо приближается глобальный OpenStack-саммит. Эта заоблачная тусовка проходит два раза в год в разных городах мира (в этот раз, например, чести принимать мероприятие удостоился Ванкувер) и дает возможность всем, кто так или иначе заинтересован в развитии экосистемы OpenStack, обменяться новостями и заодно определить, в каком направлении будет развиваться платформа. А кроме того, саммит дисциплинирует разработчиков, заставляя оперативно допиливать новые версии дистрибутивов, чтобы представить их почтеннейшему собранию. Mirantis — не исключение.Читать полностью »

Автор Сергей Кашаба

Домены в OpenStack – это метод объединения проектов или арендаторов (как они назывались в Grizzly) в независимые группы. Кроме того, они позволяют вам ограничить доступ к определенному домену. Например, как вы, наверное, помните, когда домены не применялись, пользователь, которому была назначена роль администратора в одном проекте, являлся администратором всего кластера и мог выполнять любые операции. C появлением доменов вы можете назначить пользователю роль администратора в одном домене с привилегиями администратора только в этом домене.
В данной статье будут вкратце рассмотрены некоторые ситуации, в которых домены могут вам помочь организовать свои проекты. Как только вы разберетесь с этим, мы перейдем к рассмотрению того, как на деле использовать домены с этой целью.Читать полностью »

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

Ниже – интервью с Габриелем Хёрли (Gabriel Hurley), техническим руководителем проекта OpenStack Horizon.Читать полностью »

Автор: 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