1. Введение в архитектуру Ceph и сценарии использования

1.1 Введение в Ceph

Ceph — это унифицированная распределенная система хранения, предназначенная для обеспечения лучшей производительности, надежности и масштабируемости.

Проект Ceph возник в результате работы Сейджа во время его докторской диссертации (самые ранние результаты были опубликованы в 2004 году), а затем внес свой вклад в сообщество открытого исходного кода. После нескольких лет разработки он был поддержан и широко используется многими поставщиками облачных вычислений. И RedHat, и OpenStack могут быть интегрированы с Ceph для поддержки внутреннего хранилища образов виртуальных машин.

1.2 Возможности цефалограммы

• высокая производительность
  А. Отказ от традиционной схемы адресации метаданных централизованного хранилища с использованием алгоритма CRUSH обеспечивает сбалансированное распределение данных и высокий уровень параллелизма.
  б) Учитывая изоляцию доменов отказоустойчивости, он может реализовать правила размещения реплик для различных нагрузок, таких как межмашинное помещение, осведомленность о стойке и т. д.
  C. Он может поддерживать масштабирование до тысяч узлов хранения и поддерживать данные на уровне от ТБ до ПБ.
• высокая доступность
  А. Количество копий можно гибко контролировать.
  B. Поддержка разделения доменов сбоя и строгой согласованности данных.
  C. Различные сценарии сбоя автоматически исправляются и самовосстанавливаются.
  г. Отсутствие единой точки отказа, автоматическое управление.
• Высокая масштабируемость
  А. Децентрализация.
  б. Гибкое расширение.
  в) растет линейно по мере увеличения количества узлов.
• Многофункциональный
  А. Поддерживаются три интерфейса хранения: блочное хранилище, хранилище файлов и хранилище объектов.
  B. Поддерживает настраиваемый интерфейс и поддерживает несколько языковых драйверов.

1.3 Архитектура Ceph

Поддерживаются три интерфейса:

• Объект: имеет собственный API, а также совместим с API Swift и S3.
• Блокировка: поддерживает тонкую подготовку, моментальные снимки и клоны.

• Файл: интерфейс Posix, поддерживает моментальные снимки.

  
  rados.png

1.4 Введение в основные компоненты и концепции Ceph

• Монитор Для кластера Ceph требуется небольшой кластер из нескольких мониторов, которые синхронизируют данные через Paxos для сохранения метаданных OSD.

• OSD OSD расшифровывается как Object Storage Device, процесс, ответственный за возврат определенных данных в ответ на клиентские запросы. Кластер Ceph обычно имеет много OSD.

• MDS Полное имя MDS — сервер метаданных Ceph, служба метаданных, от которой зависит служба CephFS.

• Самая нижняя единица хранения Object Ceph — это объект объекта, и каждый объект содержит метаданные и исходные данные.

• PG Полное название PG — Placement Groups, что является логичной концепцией.PG содержит несколько OSD. Введение слоя PG на самом деле предназначено для лучшего распределения и локализации данных.

• RADOS Полное название RADOS — Reliable Autonomic Distributed Object Store, что является сущностью кластера Ceph.Пользователи могут выполнять кластерные операции, такие как распределение данных и отказоустойчивость.

• Libradio Librados — это библиотека, предоставляемая Rados, поскольку RADOS — это протокол, к которому трудно получить прямой доступ, поэтому доступ к RBD, RGW и CephFS верхнего уровня осуществляется через librados, и в настоящее время она предоставляет PHP, Ruby, Java, Python, C и Поддержка С++.

• CRUSH CRUSH — это алгоритм распределения данных, используемый Ceph, аналогичный последовательному хешированию, для распределения данных в ожидаемых местах.

• RBD RBD означает блочное устройство RADOS, которое представляет собой службу блочных устройств, предоставляемую Ceph.

• RGW RGW означает шлюз RADOS.Это служба хранения объектов, предоставляемая Ceph извне.Интерфейс совместим с S3 и Swift.

• CephFS CephFS означает файловую систему Ceph, которая является службой файловой системы, предоставляемой Ceph.

1.5 Три типа хранилища — блочное хранилище

rbd.png

Типовое оборудование:дисковый массив, жесткий диск

Он в основном используется для сопоставления необработанного дискового пространства с хостом.

преимущество:

• Данные защищены такими средствами, как Raid и LVM.
• Объедините несколько дешевых жестких дисков, чтобы увеличить емкость.
• Логический диск, состоящий из нескольких дисков, повышает эффективность чтения и записи.

недостаток:

• Когда архитектура SAN используется для организации сети, стоимость оптоволоконных коммутаторов высока.
• Данные не могут быть разделены между хостами.

используемые сцены:

• Контейнер Docker, выделение дискового пространства виртуальной машины.
• хранилище логов.
• файловое хранилище.
• …

1.6 Три типа хранилища — файловое хранилище

fs.png

Типовое оборудование:FTP, NFS-сервер
Чтобы решить проблему, связанную с невозможностью совместного использования файлов блочного хранилища, существует файловое хранилище.
Настройка служб FTP и NFS на сервере — это файловое хранилище.

преимущество:

• Стоимость низкая, достаточно одной машины.
• Простой обмен файлами.

недостаток:

• Скорость чтения и записи низкая.
• Скорость передачи низкая.

используемые сцены:

• хранилище логов.
• Хранилище файлов со структурой каталогов.
• …

1.7 Три типа хранилища — объектное хранилище

rgw.png

Типовое оборудование:Распределенный сервер со встроенным жестким диском большой емкости (swift, s3)
Несколько серверов имеют встроенные жесткие диски большой емкости, установленное программное обеспечение для управления хранилищем объектов и обеспечивают внешние функции доступа для чтения и записи.

преимущество:

• Высокоскоростное чтение и запись с блочным хранилищем.
• Он имеет характеристики хранения файлов и совместного использования.

используемые сцены:(подходит для обновления данных с меньшим количеством изменений)

• Хранение изображений.
• Хранение видео.
• …

2. Процесс ввода-вывода Ceph и распределение данных

rados_io_1.png

2.1 Нормальная блок-схема ввода-вывода

ceph_io_2.png

шаг:

1. Клиент создает обработчик кластера.
2. Клиент читает файл конфигурации.
3. Клиент подключается к монитору для получения информации о карте кластера.
4. Клиент читает и записывает io для запроса соответствующего основного узла данных osd в соответствии с алгоритмом crshmap.
5. Основной узел данных osd одновременно записывает данные на два других узла-реплики.
6. Подождите, пока главный узел и два других узла-реплики закончат запись состояния данных.
7. После того, как статус записи главного узла и узла-реплики будет успешным, он возвращается клиенту, и запись ввода-вывода завершается.

2.2 Новая блок-схема основного ввода-вывода

инструкция:
Если вновь добавленное OSD1 заменяет исходное OSD4 и становится основным OSD, поскольку PG не создается на OSD1 и нет данных, то ввод/вывод на PG не может быть выполнен.Как это работает?

ceph_io_3.png

шаг:

1. Клиент подключается к монитору для получения информации о карте кластера.
2. В то же время новый мастер osd1 будет активно сообщать монитору, потому что нет данных pg, позволяющих osd2 временно взять на себя роль мастера.
3. Временный мастер osd2 полностью синхронизирует данные с новым мастером osd1.
4. Клиентский ввод-вывод для чтения и записи напрямую подключается к временному мастеру osd2 для чтения и записи.
5. osd2 получает чтение и запись ввода-вывода и одновременно записывает на два других узла реплики.
6. Подождите, пока osd2 и две другие реплики успешно запишутся.
7. Все три данных osd2 успешно записаны и возвращены клиенту.В это время чтение и запись клиента завершены.
8. Если синхронизация данных osd1 завершена, временный мастер osd2 передаст роль мастера.
9. osd1 становится главным узлом, а osd2 становится репликой.

2.3 Алгоритм ввода-вывода Ceph

ceph_io_4.png

1. Пользователи файлов должны читать и записывать файлы. Файл->Отображение объектов:
   a.ino (метаданные Файла, уникальный идентификатор Файла).
   b.ono (серийный номер объекта, сгенерированный сегментацией файла, размер блока по умолчанию — 4M).
   в. oid(идентификатор объекта: ino + ono).

2. Объект — это объект, требуемый RADOS. Ceph задает статическую хэш-функцию для вычисления значения oid, сопоставляет oid с приблизительно равномерно распределенным псевдослучайным значением, а затем выполняет побитовое И с маской для получения pgid. Отображение объекта->PG:
   а. хэш (oid) и маска-> pgid.
   б) маска = общее количество PG m (m - целая степень числа 2)-1.

3. PG (группа размещения), цель состоит в том, чтобы организовать и отобразить хранилище объектов (аналогично концепции слота в кластере Redis). В PG будет много объектов. С помощью алгоритма CRUSH подставляем в него pgid, после чего получаем набор OSD. Отображение PG->OSD: а) CRUSH(pgid)->(osd1,osd2,osd3) .

2.4 Процесс псевдокода Ceph IO

locator = object_name
obj_hash =  hash(locator)
pg = obj_hash % num_pg
osds_for_pg = crush(pg)    # returns a list of osds
primary = osds_for_pg[0]
replicas = osds_for_pg[1:]

2.5 Процесс ввода-вывода Ceph RBD

ceph_rbd_io.png

шаг:

1. Клиент создает пул и должен указать количество pg для этого пула.
2. Создайте устройство пула/образа rbd для монтирования.
3. Данные, записываемые пользователем, нарезаются на блоки, размер каждого блока по умолчанию 4M, и каждый блок имеет имя, имя — объект + порядковый номер.
4. Выделите позицию реплики каждого объекта через pg.
5. PG ищет 3 OSD по алгоритму CURSH, сохраняет этот Объект в эти три OSD.
6. osd фактически форматирует базовый диск, а общие инструменты развертывания форматируют его как файловую систему xfs.
7. Хранилищем объекта становится хранилище файла rbd0.object1.file.

2.6 Схема инфраструктуры ввода-вывода Ceph RBD

ceph_rbd_io1.png

Процесс OSD записи данных клиента:

1. В форме libbrd используйте libbrd для создания блочного устройства и записи данных на это блочное устройство.
2. Интерфейс librados вызывается локально на клиенте, а затем выполняется послойное сопоставление через pool, rbd, object и pg.На уровне PG вы можете узнать, на каких 3 OSD хранятся данные.Эти 3 OSD делятся на ведущие и ведомые.
3. Клиент устанавливает связь через SOCKET с основным OSD, передает данные для записи в первичный OSD, а первичный OSD отправляет данные другим узлам данных реплики OSD.

2.7 Пул Ceph и распространение PG

ceph_pool_pg.png

инструкция:

• Пул — это логический раздел, когда ceph хранит данные, и он действует как пространство имен.
• Каждый пул содержит определенное количество (настраиваемое) PG.
• Объекты в PG сопоставляются с разными объектами.
• Пул распространяется на весь кластер.
• Пул можно использовать в качестве домена изоляции сбоев, который можно изолировать в соответствии с различными пользовательскими сценариями.

2.8 Распределение PG расширения данных Ceph

Процесс переноса данных сценария:

• Статус 3 OSD, 4 PG
• Расширено до 4 OSD, 4 PG

статус кво:

ceph_recory_1.png

После расширения:

ceph_io_recry2.png

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

3. Механизм сердцебиения Ceph

3.1 Введение в Heartbeat

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

проблема:

• Существует компромисс между временем обнаружения неисправности и нагрузкой, вызванной пакетами пульса.
• Если частота пульса слишком высока, слишком много пакетов пульса повлияют на производительность системы.
• Если частота сердцебиения слишком низкая, это увеличит время обнаружения неисправного узла, что повлияет на доступность системы.

Стратегия обнаружения неисправностей должна быть способна:

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

3.2 Обнаружение пульса Ceph

ceph_heartbeat_1.png

Узел OSD будет прослушивать четыре порта: общедоступный, кластерный, передний и задний.

• общедоступный порт: слушайте подключения от монитора и клиента.
• кластерный порт: прослушивание подключений от одноранговых узлов OSD.
• Передний порт: сетевая карта, используемая клиентом для подключения к кластеру, которая временно используется для пульсации между кластерами.
• задний порт: сетевая карта, используемая внутри гостевого кластера. Сердцебиение между кластерами.
• hbclient: мессенджер, который отправляет пульсацию ping.

3.3 Взаимное обнаружение пульса между OSD Ceph

ceph_heartbeat_osd.png

шаг:

• OSD в одном и том же PG бьют друг друга и посылают друг другу информацию PING/PONG.
• Он обнаруживается каждые 6 секунд (фактически на этом основании будет добавлено случайное время, чтобы избежать пиков).
• Если в течение 20 с не обнаружено ответа пульса, он присоединяется к очереди отказов.

3.4 Ceph OSD и обнаружение сердцебиения Mon

ceph_heartbeat_mon.png

OSD сообщает монитору:

• Когда в OSD происходит событие (например, сбой, изменение PG).
• Самостоятельный запуск в течение 5 секунд.
• Экранное меню периодически передается в Monito.
  • OSD проверяет информацию об ошибках партнерского OSD в failure_queue.
  • Отправьте отчет об ошибке в Monitor, добавьте информацию об ошибке в очередь failure_pending, а затем удалите ее из очереди failure_queue.
  • Когда от OSD поступает контрольный сигнал в failure_queue или failure_pending, он удаляется из обеих очередей, а монитору предлагается отменить предыдущий отчет об ошибке.
  • Когда происходит повторное подключение к сети Monitor, отчет об ошибке в failure_pending будет добавлен обратно в failure_queue и снова отправлен в Monitor.
• Мониторинг статистики в автономном режиме OSD
  • Monitor собирает отчеты о сбоях партнеров из OSD.
  • Когда сбой OSD, указанный в отчете об ошибке, превышает определенный порог и имеется достаточное количество OSD для сообщения об ошибке, OSD отключается.

3.5 Сводка по обнаружению сердцебиения Ceph

Ceph определяет отказ узла OSD двумя способами: OSD-партнер сообщает об отказавшем узле, а монитор подсчитывает тактовые импульсы от OSD.

• своевременно:OSD-партнер может обнаружить сбой узла за считанные секунды и сообщить об этом монитору, а монитор переведет отказавший OSD в автономный режим в течение нескольких минут.
• Соответствующее давление:Из-за партнерского механизма отчетности OSD статистика контрольных сигналов между монитором и OSD больше похожа на страховую меру, поэтому интервал между отправкой контрольных сигналов OSD в монитор может достигать 600 секунд, а порог обнаружения монитора также может достигать 600 секунд. до 900 секунд. Ceph фактически распределяет нагрузку центрального узла на все OSD во время процесса обнаружения отказов, чтобы повысить надежность монитора центрального узла, тем самым улучшая масштабируемость всего кластера.
• Допускать джиттер сети:После того, как Монитор получает отчет OSD о своем OSD-партнере, он не сразу переводит целевое OSD в автономный режим, а периодически ожидает выполнения нескольких условий:
  • Время отказа целевого OSD превышает пороговое значение, динамически определяемое фиксированным количеством osd_heartbeat_grace и историческими условиями сети.
  • Отчеты с разных хостов доходят до mon_osd_min_down_reporters.
  • Отчет об ошибке не отменяется исходным OSD до тех пор, пока не будут выполнены первые два условия.
• диффузия:Монитор как центральный узел не пытается широковещательно уведомлять все OSD и Клиенты после обновления OSDMap, а лениво ждет, пока OSD и Клиенты не получат их. Это снижает давление монитора и упрощает логику взаимодействия.

4. Коммуникационная структура Ceph

4.1 Введение в типы коммуникационной инфраструктуры Ceph

Существует три различных реализации фреймворка сетевых коммуникаций:

• Простой режим потока
  Особенности: Для каждой сетевой ссылки создаются два потока, один для получения и один для отправки.
  Недостатки: большое количество ссылок будет генерировать большое количество потоков, которые потребляют ресурсы ЦП и влияют на производительность.
• Режим мультиплексирования ввода-вывода для асинхронных событий
  Особенности: Это широко используемый метод в современных сетевых коммуникациях. Версия k уже использует Asnyc по умолчанию.
• Метод XIO использует библиотеку сетевых коммуникаций с открытым исходным кодом accelio для достижения
  Особенности: этот метод должен полагаться на стабильность сторонней библиотеки accelio, которая в настоящее время находится на экспериментальной стадии.

4.2 Шаблоны проектирования коммуникационной среды Ceph

Шаблоны проектирования (подписаться/опубликовать):
Шаблон подписки-публикации, также известный как шаблон наблюдателя, предназначен для «определения зависимости «один ко многим» между объектами,
Когда состояние объекта изменяется, все объекты, которые зависят от него, уведомляются и обновляются автоматически».

4.3 Блок-схема коммуникационной среды Ceph

ceph_message.png

шаг:

• Accepter слушает запрос партнера и вызывает SimpleMessenger::add_accept_pipe() для создания нового канала для SimpleMessenger::pipes для обработки запроса.
• Pipe используется для чтения и отправки сообщений. Этот класс в основном состоит из двух компонентов: Pipe::Reader и Pipe::Writer, которые используются для обработки чтения и отправки сообщений.
• Messenger выступает в роли издателя сообщения, а каждый подкласс Dispatcher выступает в роли подписчика сообщения.После того как Messenger получает сообщение, он читает его через Pipe, а затем передает его Dispatcher для обработки.
• Dispatcher — это базовый класс подписчиков. Конкретный сервер подписки наследует этот класс. При инициализации он регистрируется в Messenger::dispatchers через Messenger::add_dispatcher_tail/head. После получения сообщения уведомите класс для обработки.
• DispatchQueue Этот класс используется для кэширования полученных сообщений, а затем для пробуждения потока DispatchQueue::dispatch_thread, чтобы найти внутренний Dispatch для обработки сообщений.

ceph_message_2.png

4.4 Диаграмма классов Ceph Communication Framework

ceph_message_3.png

4.5 Формат коммуникационных данных Ceph

Формат протокола связи требует, чтобы обе стороны согласовали формат данных.

Содержание сообщения в основном делится на три части:

• header // заголовок сообщения, конверт типа message
• пользовательские данные // Фактические данные, которые необходимо отправить
  • полезная нагрузка //Действовать для сохранения метаданных
  • среднее // зарезервированное поле
  • данные // чтение и запись данных
• нижний колонтитул // Конечный тег сообщения

class Message : public RefCountedObject {
protected:
  ceph_msg_header  header;      // 消息头
  ceph_msg_footer  footer;      // 消息尾
  bufferlist       payload;  // "front" unaligned blob
  bufferlist       middle;   // "middle" unaligned blob
  bufferlist       data;     // data payload (page-alignment will be preserved where possible)

  /* recv_stamp is set when the Messenger starts reading the
   * Message off the wire */
  utime_t recv_stamp;       //开始接收数据的时间戳
  /* dispatch_stamp is set when the Messenger starts calling dispatch() on
   * its endpoints */
  utime_t dispatch_stamp;   //dispatch 的时间戳
  /* throttle_stamp is the point at which we got throttle */
  utime_t throttle_stamp;   //获取throttle 的slot的时间戳
  /* time at which message was fully read */
  utime_t recv_complete_stamp;  //接收完成的时间戳

  ConnectionRef connection;     //网络连接

  uint32_t magic = 0;           //消息的魔术字

  bi::list_member_hook<> dispatch_q;    //boost::intrusive 成员字段
};

struct ceph_msg_header {
    __le64 seq;       // 当前session内 消息的唯一 序号
    __le64 tid;       // 消息的全局唯一的 id
    __le16 type;      // 消息类型
    __le16 priority;  // 优先级
    __le16 version;   // 版本号

    __le32 front_len; // payload 的长度
    __le32 middle_len;// middle 的长度
    __le32 data_len;  // data 的 长度
    __le16 data_off;  // 对象的数据偏移量


    struct ceph_entity_name src; //消息源

    /* oldest code we think can decode this.  unknown if zero. */
    __le16 compat_version;
    __le16 reserved;
    __le32 crc;       /* header crc32c */
} __attribute__ ((packed));

struct ceph_msg_footer {
    __le32 front_crc, middle_crc, data_crc; //crc校验码
    __le64  sig; //消息的64位signature
    __u8 flags; //结束标志
} __attribute__ ((packed));

5. Алгоритм Ceph CRUSH

5.1 Проблемы алгоритмов распределения данных

• Распределение данных и балансировка нагрузки:
  А. Распределение данных сбалансировано, так что данные могут быть равномерно распределены по каждому узлу.
  б) Балансировка нагрузки, чтобы нагрузка операций чтения и записи доступа к данным была сбалансирована на каждом узле и диске.
• Гибкая реакция на масштабирование кластера
  A. Система может легко добавлять или удалять узловые устройства и обрабатывать сбои узлов.
  б) После добавления или удаления узловых устройств баланс данных может быть достигнут автоматически, и будет перенесено как можно меньше данных.
• Поддержка крупномасштабных кластеров
  А. Метаданные, которые должны поддерживаться алгоритмом распределения данных, относительно невелики, и объем вычислений не может быть слишком большим. По мере увеличения размера кластера накладные расходы алгоритма распределения данных становятся относительно небольшими.

5.2 Описание алгоритма Ceph CRUSH

• Полное название алгоритма CRUSH: Controlled Scalable Decentralized Placement of Replicated Data, управляемый, масштабируемый и распределенный алгоритм размещения реплик данных.
• Алгоритм процесса преобразования pg в OSD называется алгоритмом CRUSH. (Объект должен сохранить три копии, то есть его нужно сохранить на трех osds).
• Алгоритм CRUSH является псевдослучайным процессом, он может случайным образом выбирать набор OSD из всех OSD, но результат каждого случайного выбора одной и той же PG неизменен, то есть отображаемый набор OSD фиксирован.

5.3 Принцип алгоритма Ceph CRUSH

Фактор алгоритма CRUSH:

• Иерархическая карта кластера
  Отражает физическую топологию уровня системы хранения. Он определяет статическую топологическую структуру кластера OSD с иерархической взаимосвязью. Уровень OSD позволяет алгоритму CRUSH добиться осведомленности о стойке при выборе OSD, то есть посредством определения правил копии можно распределять по разным стойкам, разным компьютерным залам и обеспечивать безопасность данных.
• Placement Rules
  Определяет правила выбора реплик объектов PG.С помощью этих правил пользователи могут устанавливать свои собственные правила, а пользователи могут настраивать распределение реплик в кластере.

5.3.1 Иерархическая карта кластеров

ceph_crush.png

CRUSH Map имеет древовидную структуру, OSDMap записывает больше атрибутов OSDMap (информация об эпохе/fsid/пуле и ip osd и т.д.).

Листовой узел — это устройство (то есть osd), а остальные узлы называются узлами корзины.Эти корзины являются фиктивными узлами, которые можно абстрагировать в соответствии с физической структурой.Конечно, древовидная структура имеет только один конечный корневой узел называется корневым узлом.Узел виртуального сегмента может быть абстракцией центра обработки данных, абстракцией компьютерного зала, абстракцией стойки, абстракцией хоста и т. д.

5.3.2 Правила размещения для стратегии распространения данных

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

rule replicated_ruleset  #规则集的命名，创建pool时可以指定rule集
{
    ruleset 0                #rules集的编号，顺序编即可   
    type replicated          #定义pool类型为replicated(还有erasure模式)   
    min_size 1                #pool中最小指定的副本数量不能小1
    max_size 10               #pool中最大指定的副本数量不能大于10       
    step take default         #查找bucket入口点，一般是root类型的bucket    
    step chooseleaf  firstn  0  type  host #选择一个host,并递归选择叶子节点osd     
    step emit        #结束
}

5.3.3 Тип случайного алгоритма сегмента

ceph_bucket.png

• Общие сегменты: подходит для всех дочерних узлов, чтобы они имели одинаковый вес и редко добавляли или удаляли элементы.
• сегменты списка: для типов масштабирования кластера. Добавить элемент, сгенерировать оптимальное перемещение данных, найти элемент, временная сложность O(n).
• ведра дерева: Степень ответственности за нахождение O (log n).При добавлении или удалении листовых узлов node_id других узлов остается неизменным.
• соломенные ведра: позволяет всем предметам честно «конкурировать» с другими предметами, как в лотерее. При нахождении реплики каждому элементу в ведре соответствует соломинка случайной длины, и выигрывает (выбирается) соломинка с наибольшей длиной, добавление или пересчет, перемещение данных между поддеревьями обеспечивает оптимальный план решения.

5.4 Случай алгоритма CRUSH

инструкция:
В кластере есть несколько sas и ssd дисков.Сейчас есть направление бизнеса у которого приоритет производительности и доступности выше чем у других направлений бизнеса.Могут ли данные этого качественного направления бизнеса храниться на ssd диске?

обычный пользователь:

ceph_sas.png

Высококачественные пользователи:

ssd.png

Правила конфигурации:

ceph_crush1.png

6. Индивидуальный QOS Ceph RBD

6.1 Введение в QOS

QoS (Quality of Service, качество обслуживания) возникло из сетевых технологий, оно используется для решения таких проблем, как задержка и перегрузка сети, и может обеспечить лучшие возможности обслуживания для определенных сетевых коммуникаций.

проблема:
Емкость iIO всего нашего кластера Ceph ограничена, например пропускная способность, IOPS. Как предотвратить борьбу пользователей за ресурсы, как обеспечить высокую доступность всех пользовательских ресурсов в кластере и как обеспечить доступность высокооптимизированных пользовательских ресурсов. Следовательно, нам нужно разумно распределять ограниченную пропускную способность ввода-вывода.

6.2 Типы операций ввода-вывода Ceph

• ClientOp: чтение и запись запросов ввода-вывода от клиентов.
• SubOp: запрос ввода/вывода между osd. В основном это запросы на чтение и запись данных между репликами, созданные клиентским вводом-выводом, а также запросы ввода-вывода, вызванные синхронизацией данных, сканированием данных и балансировкой нагрузки.
• SnapTrim: удаление данных снимка. После отправки команды удаления моментального снимка от клиента удалите соответствующие метаданные и вернитесь напрямую, а затем фоновый поток удалит реальные данные моментального снимка. Скорость удаления косвенно контролируется скоростью snaptrim.
• Scrub: Scrub для обнаружения скрытых ошибок данных объектов, Scrub для сканирования метаданных и deep Scrub для общего сканирования объектов.
• Восстановление: Восстановление и миграция данных. Расширение/уменьшение кластера, сбой/повторное присоединение osd и т. д.

6.3 Официальный принцип QOS Ceph

ceph_mclok_qos.png

mClock — это алгоритм планирования ввода-вывода на основе меток времени, впервые предложенный компанией Vmware для централизованного управления системами хранения. (В настоящее время официальный модуль QOS является полуфабрикатом).

Основная идея:

• резервирование Резервирование, представляющее минимальный ресурс ввода-вывода, который получает клиент.
• вес Вес, указывающий долю общих ресурсов ввода/вывода, занимаемых клиентом.
• limit Верхний предел, указывающий самые высокие ресурсы ввода-вывода, доступные клиенту.

6.4 Принцип индивидуального QOS

6.4.1 Введение в алгоритм Token Bucket

ceph_token_qos.png

На основе алгоритма корзины токенов (TokenBucket) реализован набор простых и эффективных функций qos, отвечающих основным потребностям пользователей облачной платформы.

Основная идея:

• Бросьте токены в корзину с определенной скоростью.
• Пакеты сначала классифицируются в соответствии с предустановленными правилами сопоставления.Пакеты, которые не соответствуют правилам сопоставления, не должны обрабатываться сегментом маркеров и отправляются напрямую.
• Пакеты, соответствующие правилам сопоставления, требуют для обработки сегмента токенов. Когда в корзине достаточно токенов, пакет можно продолжать отправлять, и количество токенов в корзине соответственно уменьшается в соответствии с длиной пакета.
• Когда в корзине маркеров недостаточно токенов, пакет не может быть отправлен, и пакет может быть отправлен только тогда, когда в корзине сгенерирован новый токен. Это может ограничить поток пакетов, чтобы он был меньше или равен скорости генерации токена, чтобы ограничить поток.

6.4.2 Процесс алгоритма корзины токенов RBD

ceph_token1.png

шаг:

• Пользователь инициирует запрос на получение асинхронного ввода-вывода в образе.
• Запрос поступает в очередь ImageRequestWQ.
• Добавьте алгоритм корзины маркеров TokenBucket, когда ImageRequestWQ находится вне очереди.
• Скорость ограничивается алгоритмом корзины маркеров, а затем отправляется в ImageRequest для обработки.

6.4.3 Структурная схема алгоритма корзины токенов RBD

Существующая схема кадра:

ceph_qos2.png

Диаграмма структуры алгоритма графа токенов:

ceph_qos_token2.png

Информация об авторе

автор:Ли Ханг
Личный профиль:Многолетний опыт низкоуровневой разработки, богатый опыт разработки высокопроизводительного nginx и кластера Redis с распределенным кешем, на данный момент работаю в Ceph около двух лет.
Последовательно работал в 58.com, Autohome и Youku Tudou Group. В настоящее время работает в отделе эксплуатации и обслуживания базовой платформы Didi, отвечая за разработку, эксплуатацию и обслуживание распределенных кластеров Ceph.
Личные основные технические проблемы: разработка высокопроизводительного Nginx, распределенное кэширование, распределенное хранилище.