`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

IT-пятница с GigaCloud. Сессия 5

+33
голоса

Первый в этом году семинар собрал рекордное количество участников, что свидетельствует о росте его популярности. Он начался с выступления одного из наиболее частых докладчиков — архитектора OpenStack Алексея Кириченко.

Темой его презентации была гиперконвергентная распределенная система хранения на основе решения Ceph.

Он отметил, что сегодня получают распространение распределенные файловые хранилища данных. На фоне этой тенденции внимание компаний привлекает Ceph — свободная программная объектная сеть хранения с открытой архитектурой, обеспечивающая как файловый, так и блочный интерфейсы доступа. Это ПО разрабатывает и поддерживает сообщество открытого исходного кода Ceph.

IT-пятница с GigaCloud. Сессия 5

Алексей Кириченко: «На фоне распространения распределенных файловых хранилищ данных внимание компаний привлекает Ceph»

Характерной особенностью Ceph является хорошая масштабируемость. ПО использоваться на системах, состоящих как из нескольких Linux-машин, так и из тысяч узлов: известно об эксплуатации систем на Ceph размером в сотни петабайт; встроенные механизмы продублированной репликации данных обеспечивают высокую живучесть системы, при добавлении или удалении новых узлов массив данных автоматически перебалансируется с учетом изменений.

Если принято решение перейти на гиперконвергентное распределенное файловой хранилище, то важно правильно подобрать аппаратные средства. В противном случае отсутствует гарантия устойчивой работы. При создании Ceph-кластера важно понимать, что его нельзя построить «за копейки», как иногда пишут в Интернете. При использовании дешевых серверов и коммутаторов кластер рано или поздно распадется, и данные могут быть потеряны.

При сборке серверов прежде всего нужно обращать внимание на оперативную память, процессоры, дисковые контроллеры. Из тестов, которые проводил докладчик, следует, что на 1 ТБ объема дискового пространства должен приходиться 1 ГБ ОЗУ. Количество же IOPS определяется мощностью процессора. Она особенно важна при использовании SSD — при слабом процессоре они будут простаивать. Результаты тестов показывают, что если необходимо получить от узла 1000 IOPS, то на них должна приходиться частота процессора 1 ГГц. Что касается LAN, то для высоких нагрузок необходимо использовать 10GE.

Как правило, архитектура СХД состоит из нескольких уровней. На самом нижнем находятся диски. Ими могут быть HHD, SSD или NVMe. На следующем находится служба, отвечающая за доступ к дискам. Все это собирается в кластер, а на уровне клиента можно организовывать пулы. На основе этих пулов можно сформировать два типа файловых хранилищ: CephFS и CephRBD (Ceph RADOS Block Device).

RADOS (Reliable Autonomic Distributed Object Store) — это служба хранения объектов с открытым исходным кодом, являющаяся неотъемлемой частью распределенной системы хранения Ceph. Система Ceph RADOS обычно состоит из большого набора стандартных серверов, также известных как узлы хранения. Типичные случаи использования системы Ceph RADOS — это автономная система хранения или серверная часть для OpenStack Block Storage.

RADOS может масштабироваться до тысяч аппаратных устройств, используя программное обеспечение для управления, которое работает на каждом из отдельных узлов хранения. Программное обеспечение предоставляет такие функции хранения, как тонкое выделение ресурсов, моментальные снимки и репликацию. Алгоритм, называемый контролируемой репликацией при масштабируемом хешировании (Controlled Replication Under Scalable Hashing, CRUSH), определяет, как данные реплицируются и сопоставляются с отдельными узлами.

Для построения кластера имеются два руководства. Более старое рекомендует использовать FileStore — управляемую службу хранения файлов, а новое — BlueStore. Последнее позволяет получить более высокую степень утилизации подключаемых к кластеру дисков.

Еще одним важным параметром, который задается при создании пула, является PG (Placement Group). Он включает набор правил для группы объектов, при этом группа объектов может находиться только в пределах одного OSD (Object Storage Daemon), фактически, в пределах одного диска.

В заключение докладчик рассказал, в чем разница между блочным, файловым и объектным хранилищем.

В семинаре принял участие гость из Беларуси, директор по развитию Павел Богданов из компании hoster.by, который рассказал о Linux-контейнерах на базе LXD (демон, расширение гипервизора контейнеров LXC).

IT-пятница с GigaCloud. Сессия 5

Павел Богданов: «Своеобразной вехой в истории контейнеров послужил 2000 г., когда были запущены проекты FreeBSD Jail и OpenVZ»

Обратившись к краткой истории контейнеров, выступающий отметил, что они появились как альтернатива ВМ, поскольку обладали более быстрым откликом и лучшей утилизацией ресурсов. При этом возникли проблемы с безопасностью, связанные с виртуализацией на уровне ОС.

Своеобразной вехой в истории послужил 2000 г., когда были запущены проекты FreeBSD Jail и OpenVZ. В то время понятия «контейнер» еще не придумали, и это называлось виртуализацией на уровне ОС, или программной виртуализацией. В 2007–2008 гг. возникла группа cgroups, на базе которой начали появляться LXC (Linux containers), Docker, Systemd и т.д., и с этого момента системы начали называть контейнерами.

Для запуска контейнера необходимы cgroups + namespaces, которые обеспечивают ограничения и изоляцию, корневая файловая система (root fs), соответствующие сетевые настройки и менеджер контейнеров.

Сегодня контейнеры развиваются в двух направлениях. Первое — как конкуренция с ВМ, когда внутри контейнера создается образ ВМ, и с ним работают, как с ВМ. Второе, получающее распространение направление, — это переход к микросервисам, что отчасти решает проблемы с безопасностью.

Заключительный доклад об опыте GigaCloud в отказоустойчивом подключении облака к Интернету сделал сетевой инженер Алексей Котов. Следуя правилам «хорошего тона», он вначале привел определение отказоустойчивости, которое не грех еще раз напомнить.

IT-пятница с GigaCloud. Сессия 5

Алексей Котов: «Компании, которые внедряют крупные проекты, должны уделять избыточности повышенное внимание»

Итак, отказоустойчивость — свойство системы сохранять свою работоспособность после отказа одного или нескольких составных компонентов.

Отказоустойчивость определяется количеством любых последовательных единичных отказов компонентов, после которых сохраняется работоспособность системы в целом, а также временем, за которое система восстанавливает свою работоспособность после аварийной ситуации.

Базовый уровень отказоустойчивости подразумевает защиту от отказа одного любого элемента — исключение единой точки отказа. Основной способ повышения отказоустойчивости — избыточность.

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

В контексте сети на каждом из уровней эталонной модели OSI есть свои системы отказоустойчивости. Так, на физическом уровне имеются системы обхода (порты bypass), через которые передается трафик при выходе порта из строя; на канальном — протокол связывающего дерева STP. Позже появилась агрегация портов и стеки коммутаторов, что позволило сделать отказоустойчивую схему без использования STP, который характеризуется большими задержками. На сетевом уровне любой из динамических протоколов маршрутизации является отказоустойчивым по природе.

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

При построении сети GigaCloud выполнялись следующие требования. Коммутаторы на уровне доступа должны быть объединены в стек, зарезервированы по питанию, также должны быть зарезервированы нисходящие и восходящие каналы. Маршрутизаторы на уровне агрегации должны были обеспечивать взаимодействие с пограничными маршрутизаторами, резервирование друг друга, маркировку и шейпинг входного трафика, частичную защиту от DDoS-атак, балансировку трафика между ЦОД, содержание и резервирование клиентских шлюзов, распределение ненумерованного пула IP-адресов клиентов. Пограничные маршрутизаторы на уровне ядра были ответственны за взаимодействие с внешними ISP, резервирование друг друга, балансировку трафика между двумя ЦОД, маркировку трафика и шейпинг, частичную защиту от DDoS-атак.

В итоге, обобщенная схема отказоустойчивого кластера имеет два плеча и двух внешних интернет-провайдеров. В каждом плече установлены по два зарезервированных маршрутизатора и по два зарезервированных коммутатора уровня L2. Отказ любого из провайдеров резервируется вторым для каждого ЦОД.

Результаты тестирования показали, что в данной схеме допускается одновременный отказ двух маршрутизаторов либо по вертикали, либо по горизонтали и выход из строя одного из стека коммутатора в любом ЦОД. Схема позволяет плавно выводить из эксплуатации одновременно до двух маршрутизаторов с целью дальнейшего их обслуживания или замены.

Следующая встреча в рамках «ИТ-пятницы с GigaCloud» состоится 1-го февраля. Организаторы приглашают к участию слушателей и докладчиков. Для этого необходимо зарегистрироваться.


Вы можете подписаться на наш Telegram-канал для получения наиболее интересной информации

+33
голоса

Напечатать Отправить другу

Читайте также

 
 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT