Ceph является системой с открытым исходным кодом, распределённого, горизонтально масштабируемого, определяемого программным обеспечением хранения данных (SDS, software-defined storage). Благодаря применению алгоритма CRUSH (Controlled Replication Under Scalable Hashing, Управляемых масштабируемым хешированием репликаций), Ceph исключает необходимость в централизованных метаданных и может распределять имеющуюся нагрузку по всем присутствующим в кластере узлам. Так как CRUSH является алгоритмом, размещение данных вычисляется вместо того, чтобы полагаться на табличные поиски и может масштабироваться до сотен петабайт без риска бутылочных горлышек и наличия сопутствующих одиночных точек отказа. Клиенты также создают прямые соединения с теми серверами, которые хранят требуемые данные и поэтому во всех путях данных отсутствуют узкие места.

Ceph предоставляет три основных типа хранения, которыми явдяются блоки через RBD (RADOS Block Devices), файлы посредством CephFS (Ceph Filesystem) и объекты при помощи шлюза RADOS (Reliable Autonomous Distributed Object Store, Безотказного автономного распределённого хранилища объектов), который предоставляет совместимое с S3 (Simple Storage Service) и Swift хранилище.

Ceph является чистым решением SDS (программно определяемого хранилища) и это означает, что вы вольны работать с ним на общедоступных аппаратных средствах, если только они предоставляют достаточные гарантии для согласованности данных. Дополнительная информация о рекомендуемых типах оборудования может быть найдена далее в этой главе. Именно это является главным разработке для отрасли хранения, которая обычно страдает от прямой привязки к производителю. Несмотря на то, что имелось множество проектов с открытым исходным кодом для предоставления услуг хранения. Очень немногие из них смогли предоставить такие как у Сузр масштабируемость и высокую надёжность не требуя при этом специализированных аппаратных средств.

Центральным уровнем хранения в Ceph является RADOS, который предоставляет, как об этом заявляет само название, некоторое хранение объектов на которых строятся и распространяются протоколы хранения более высокого уровня. Данный уровень RADOS в Ceph включает в себя большое число OSD. Каждое OSD полностью независимо и образует одноранговое (peer-to-peer) взаимодействие для формирования некоторого кластера. Каждый OSD обычно ставится для ОС в соответствие (mapped) некому отдельному физическому диску через базисный HBA (host bus adapter, адаптер основной шины) в противоположность с обычным подходом представления некоторого числа дисков через контроллер RAID (Redundant Array of Independent Disks, Массива независимых дисков с избыточностью).

Другим ключевым компонентом в каком бы то ни было кластере Ceph являются мониторы; именно они отвечают за формирование кворума кластера с использованием Paxos. Данные мониторы напрямую не вовлекаются в имеющийся путь данных и не имеют тех же самых требований к производительности, что и OSD. Они в основном используются для предоставления известным состояния кластера, включая членство, настройки и статистические данные через применение различных карт (maps) кластера. Такие карты кластера используются как компонентами кластера Ceph, так и клиентами, для описания всей топологии кластера и делают возможным безопасное сохранение данных в конкретном правильном местоположении. Имеется ещё один последний компонент - диспетчер - который отвечает за настройку и статистические данные. Благодаря тем масштабам, с которыми намеревается работать Ceph, можно понять, что отслеживание состояния и размещение каждого отдельного объекта в данном кластере могло бы стать с точки зрения вычислений очень затратным. Ceph решает эту проблему применяя хэширование лежащих в его основе имён базовых объектов для размещения объектов в ряде PG (placement groups, групп размещения). Затем некий алгоритм с названием CRUSH применяется для помещения групп размещения в имеющихся OSD. Это снижает потребность в отслеживании миллионов объектов до намного более управляемого числа групп размещения, обычно измеряющихся в тысячах.

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

Для получения дополнительной информации о том, как работают все внутренности Ceph, настоятельно рекомендуется прочесть официальную документацию, а также все тезисы, написанные Сейджем Вейлем (Sage Weil), создателем и первоначальным архитектором Ceph. {Прим. пер.: см. Приложение B}.

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

Теперь мы рассмотрим некоторые наиболее распространённые варианты применения Ceph и обсудим некоторые из тех причин, которые лежат в основе такого выбора.

Виртуализация на основе OpenStack или KVM

Ceph исключительно соответствует предоставлению хранилища некоторой среде OpenStack; на самом деле, Ceph в настоящее время является наиболее популярным вариантом. OpenStack представил в 2018 году обзор, согласно которому 61% из опрошенных пользователей OpenStack применяли Ceph для предоставления хранилищ в OpenStack. Блочное устройство OpenStack Cinder применяет RBD Ceph для предоставления ВМ блочных томов, а OpenStack Manila, FaaS (File as a Service, Файлов как службы), хорошо интегрирована с CephFS. Имеется целый ряд причин почему Ceph настолько хорошее решение для OpenStack:

Если вы не используете OpenStack или не планируете применять его, Ceph также очень хорошо интегрирован с виртуализацией KVM. {Прим. пер.: всё сказанное, например, верно и для Proxmox, и для контейнеризации Docker/ Kubernetres подробнее....}

Большая куча блочных хранилищ

Благодаря возможности проектировать и строить эффективные в стоимостном отношении узлы OSD, Ceph делает возможным для вас построение больших высокопроизводительных кластеров хранения, которые очень выгодны с точки зрения цены при их сопоставлении с альтернативными вариантами. Редакция Luninious внесла поддержку удаляющего кодирования для рабочих нагрузок с блочными устройствами и файлами, что ещё больше увеличило привлекательность Ceph для такого рода задач.

Объектное хранилище

Тот факт, что основной центральный сердцевинный уровень RADOS является хранилищем объектов, означает что Ceph превосходен при предоставлении хранения через протоколы S3 и Swift. Ceph в настоящее время один из наилучших рекордов совместимости соответствия API S3. Если стоимость, латентность или безопасность данных рассматриваются при использовании решений хранения объектов в общедоступном облаке, работа с вашим собственным кластером Ceph для предоставления хранилища объектов может быть идеальным вариантом применения.

Объектное хранилище применяемое для индивидуальных приложений

Применяя librados вы можете получить своё собственное домашнее приложение для прямого общения с лежащим в основе уровнем RADOS Ceph. Это может великолепно упростить саму разработку вашего приложения и снабдит вас прямым доступом к высокопроизводительному надёжному хранилищу. Некоторые более продвинутые свойства librados, которые позволяют вам собирать ряд операций в единую атомарную операцию также очень тяжело выполнять в имеющихся решениях хранения.

Распределённая файловая система - веб ферма

Некая фабрика веб серверов, каждому из которых необходим доступ к одним и тем же файлам с тем, чтобы все они могли обслуживать одно и то же содержимое, в не зависимости от того к кому из них подключается определённый клиент. Обычно для предоставления распределённого файлового доступа предоставлялось бы решение NFS с HA (high-availability, высокой доступностью), однако оно может начинать сталкиваться с определёнными ограничениями при масштабировании. CephFS может предоставить некую распределённую файловую систему для хранения такого веб содержимого и позволять его монтирование по всем имеющимся в данной ферме веб серверам.

Распределённая файловая система - NAS или замена файлового сервера

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

Бигдата

Большие данные являются концепцией анализа больших объёмов данных, которые не вписываются в традиционные системы анализа данных или для которых применение методов анализа было бы слишком сложным. Большие данные, как правило, требуют систем хранения, которые одновременно обладают ёмкостью для хранения больших объёмов данных и обеспечивают масштабируемую производительность. Ceph может удовлетворять оба этих требования, а следовательно, является идеальным кандидатом для предоставления масштабируемых хранилищ системам больших данных.

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

SSD великолепны. За последние 10 лет они значительно упали в стоимости, причём все данные свидетельствуют о том, что они продолжат это. Они имеют возможность предоставления времени доступа с на порядки меньшими значениями по сравнению со шпиндельными дисками и потреблять меньшую мощность.

Одним важным понятием, которое надо уяснить об SSD, является тот факт, что хотя их задержки при чтении и записи обычно измеряются в десятках микросекунд, для того чтобы перезаписать некие имеющиеся данные в каком бы то ни было блоке флеш- памяти, это потребует удаление целиком всего данного блока, прежде чем такая запись осуществится. Обычно размер блока флеш- памяти в SSD может составлять 128кБ и даже некие операции ввода/ вывода по 4кБ потребуют прочтения всего блока целиком, удаления и последующей окончательной записи всех существующих данных и новой операции ввода/ вывода. Данная операция удаления может потребовать нескольких миллисекунд и без наличия интеллектуальных процедур во встроенном программном обеспечение SSD может делать запись мучительно медленной. Для обхода данного ограничения SSD снабжаются неким буфером оперативной памяти, тем самым он может немедленно подтвердить запись, в то время как встроенное программное обеспечение внутренне ещё перемещает данные по блокам фэш- памяти для оптимизации всего процесса перезаписи и уровня износа. Однако, такой буфер оперативной памяти является энергозависимой памятью и может в нормальных условиях приводить в результате к возможности утраты данных в случае внезапного пропадания электропитания. Во избежание этого, SSD могут иметь защиту от потери электропитания, которое выполняется наличием большей некоторой ёмкости на борту, для сохранения мощности под сброс всех отложенных записей во флеш- память.

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

Прежде чем мы перейдём к моделям корпоративного уровня, стоит просто дать пояснения почему вы ни при каких условиях не должны применять предыдущие модели SSD для Ceph. Эти причины перечислены в следующем перечне:

SSD корпоративного уровня

Наибольшая разница между бытовыми и корпоративными SSD состоит в том, что некий корпоративный SSD должен предоставлять гарантию что когда он отвечает системе хоста о том, что данные были безопасно сохранены, это действительно так. Именно это означает что ели, скажем, внезапно в некоторой системе пропадает электропитание, все те данные, которые данная операционная система считает зафиксированными на диске, будут на самом деле сохранены в флеш- памяти. Более того, следует также ожидать, что для ускорения скорости записи, но при этом с сохранением безопасности состояния данных, данные SSD будут содержать суперконденсаторы для предоставления достаточной мощности на сброс всего буфера SSD в флеш- память в случае возникновения условия утраты электроснабжения.

SSD корпоративного уровня обычно предоставляются в некотором числе различных предпочтений для предоставления широкие стоимостные варианты за ГБ и сбалансированное количество допустимых перезаписей.

Корпоративные - для интенсивного чтения

SSD для интенсивного чтения - своего рода маркетинговый термин. Все SSD будут запросто обрабатывать операции чтения, однако это название ссылается на более низкое значение возможных перезаписей. Тем не менее, они будут предлагать наилучшую стоимость за ГБ. Эти SSD часто будут иметь износостойкость 0.3-1 на протяжении 5-ти летнего периода DWPD (drive writes per day, записей диска в день). Это означает, скажем, что у вас будет иметься возможность записи 400ГБ в день на некий SSD объёмом 400ГБ и ожидать при этом что он будет работать на протяжении 5 лет. Если вы пишите на него по 800ГБ в день, это будет гарантировать по крайней мере два с половиной года. Как правило, для большинства нагрузок Ceph, такие диапазоны SSD обычно считаются недостаточными для устойчивости к количеству перезаписей.

Корпоративные - для обычного применения

Корпоративные - для обычного применения

SSD обычного применения будут нормально предоставлять от трёх до пяти DWPD и являются хорошим балансом стоимости и устойчивости к количеству перезаписей. Что касается Ceph, они, как правило, будут хорошим выбором для некоторого OSD на основе SSD в предположении, что рабочая нагрузка такого кластера Ceph не планирует интенсивной перегруженности записями. Они также представляют исключительный выбор для хранения разделов DB BlueStore в гибридном кластере HDD/ SSD.

Корпоративные - для интенсивной записи

Предназначенные для интенсивной записи SSD являются наиболее затратным типом SSD. Они часто предлагают устойчивость к общему числу перезаписей до 10 DWPD и более. Они должны применяться для OSD SSD если планируются очень интенсивные рабочие нагрузки операций записи. Если в вашем кластере всё ещё применяется устаревший файловый метод хранения объектов, тогда SSD с высоким числом перезаписей также рекомендуются для их журналов.

Для всех типов развёртываний Ceph именно BlueStore является рекомендуемым к применению по умолчанию для хранения объектов. Последующая информация применима только относительно тех кластеров, которые всё ещё применяют файловое хранение. Подробности того как осуществляют свою работу файловые хранилища и зачем они были заменены на BlueStore обсуждается в Главе 3, BlueStore.

Для понимания важности выбора верного SSD при работе с файловым хранением мы должны понимать, что из за ограничений в обычных файловых системах POSIX на их способность предоставлять атомарные транзакции для определённых порций данных, требуются некий журнал чтобы иметь возможность отката транзакции когда она не может быть выполнена целиком. Если для такого журнала не используется никакой отдельный SSD, для него отводится отдельный раздел. Всякая обрабатываемая этим OSD запись будет вначале записана в такой журнал, а затем сброшена в свою основную область хранения на данном диске. Это является основной причиной, по которой предлагается применять SSD в качестве некоторого журнала для шпиндельных дисков. Такая двойная запись сурово воздействует на производительность шпиндельных дисков, что в основном вызывается самой природой случайного перемещения всех дисковых головок между областями журнала и данных.

Точно так же OSD SSD всё ещё требуют некоего журнала и поэтому они будут испытывать примерно удвоение общего числа записей и тем самым предоставлять половину ожидаемой клиентом производительности.

Как мы смогли увидеть, не все модели SSD равны, причём требования Ceph могут сделать выбор правильного достаточно сложным процессом. К счастью, можно провести быструю проверку, чтобы установить потенциал SSD для использования в качестве журнала Ceph.

Для OSD BlueStore рекомендуется 3 ГБ памяти для всякого HDD OSD и 5 ГБ для SSD OSD. Положа руку на сердце, имеется целый ряд переменных, из которых выводится данная рекомендация, но достаточно напомнить, что вы никогда не пожелаете обнаружить себя в ситуации, когда ваш OSD работает с недостаточной оперативной памятью и любая дополнительная память будет применена для повышения производительности. Помимо основного значения использования OSD оперативной памяти, главной переменной эффективного применения оперативной памяти является общее число исполняемых на OSD групп размещения (PG). Хотя общий размер данных и влияет на использование оперативной памяти, он остаётся в тени от воздействия общего число PG. Некий работающий в пределах рекомендаций в 200 PG на OSD жизнеспособный кластер скорее всего будет использовать менее 4ГБ оперативной памяти на OSD.

Однако в некотором кластере, в котором общее число групп размещения было установлено выше значения из практики применения, использование оперативной памяти будет выше. Также стоит отметить, что когда OSD удаляется из кластера, дополнительные PG будут помещены в остающиеся OSD для перебалансировки данного кластера; это также увеличивает потребление памяти помимо самих по себе операций восстановления. Такие всплески потребления оперативной памяти могут порой вызывать каскадные отказы если было предоставлено недостаточно оперативной памяти. Для снижения риска случайного уничтожения процессов OSD поглотителем Linux OOM (out-of-memory, нехватки памяти) в случае возникновения ситуации недостаточной памяти, всегда следует предоставлять некий большой раздел подкачки страниц (swap) на SSD.

Цель предоставления около 4 ГБ для OSD с HDD и 5 ГБ для OSD с SSD является минимумом; её следует рассматривать как абсолютный минимум, а 5 ГБ/ 6 ГБ (соответственно HDD/ SSD) на OSD было бы идеальным объёмом. При наличии как BlueStore, так и файлового хранения, вся установленная в сервере дополнительная память может применяться для кэширования данных, снижая латентность чтения в операциях клиента. Файловое хранение применяет кэширование страниц Linux, а следовательно ОЗУ применяется автоматически. Для BlueStore нам требуется вручную настраивать значение предела памяти для выделения дополнительной памяти под её применение под кэширование; более подробно это будет рассмотрено в Главе 3, BlueStore.

Если ваш кластер всё ещё работает с файловым хранением, в зависимости от вашей рабочей нагрузки и подлежащих применению в OSD Ceph размеров шпиндельных дисков для гарантии того, что сама операционная система имеет возможность достаточного кэширования всех записей узлов каталогов и файлов из файловой системы, применяемой для хранения всех объектов Ceph. Всё это может повлиять на размер оперативной памяти, который вы собираетесь настроить в своих узлах и более подробно описывается в разделе данной книги, посвящённом тонкой настройке.

Вне зависимости от размера настраиваемой памяти всегда следует применять паять с ECC.

Ceph официально рекомендует использовать мощность ЦПУ в 1 ГГц для каждого OSD. К сожалению, в действительности всё не так просто как представляет эта рекомендация. В официальных рекомендациях не указывается, что ввод/ вывод также требуют мощности ЦПУ и это не просто фигура речи статистики. Имеет смысл задуматься об этом: сам ЦПУ применяется тогда, когда есть какая- либо работа. Когда нет ввода/ вывода, никакой ЦПУ не требуется. Однако масштабируется это иначе: чем больше операций ввода/ вывода, тем больше потребность в ЦПУ. Официальная рекомендация является хорошей выигрышной ставкой для OSD на основе шпиндельных дисков. Когда некий узел OSD снабжён быстрыми OSD, часто можно обнаружить что мы потребляем в несколько раз больше этой рекомендации. Что ещё больше всё усложняет, так это то, что текущие потребности в ЦПУ разнятся в зависимости от размеров операций ввода/ вывода, чем большеп операции, тем больше ЦПУ они требуют. {Прим. пер.: разгрузить ЦПУ позволяет применение RDMA, обсуждаемое в Приложении A.}

Если узел OSD начинает бороться за ресурсы ЦПУ, это может привести к тому, что OSD начнёт завершаться по тайм- ауту и выходить из состава данного кластера, причём зачастую повторно присоединяться через несколько секунд позже. Такие непрерывные потери и восстановления ведут к размещению дополнительного напряжения в и без того уже ограниченные ресурсы ЦПУ, вызывая каскадные отказы.

Хорошим целевым значением было бы приблизительно 1- 10 МГц на операцию ввода/ вывода, относительно соответствующего ввода/ вывода 4кБ- 4МБ. Как и обычно, для выхода в жизнь следует провести тестирование чтобы убедиться, что требования ЦПУ соответствуют и обычным, и стрессовым нагрузкам ввода/ вывода. Кроме того, применение сжатия и контрольных сумм в BlueStore будет использовать ЦПУ дополнительно для ввода/ вывода и свои вычисления следует умножать на определённое значение при обновлении того кластера, который изначально работал с файловым хранением. Пулы с удаляющим кодированием также потребляют ЦПУ дополнительно по соотношению с пулами репликаций. Использование ЦПУ очень сильно различается в зависимости от самого типа и профиля удаляющего кодирования, а следовательно для получения лучшего представления необходимых требований следует выполнять тестирование.

Другим аспектом выбора ЦПУ, который является ключевым при определении производительности в Ceph, является тактовая частота имеющихся ядер. Большая часть пути ввода/ вывода в Ceph является однопоточной и, следовательно, чем больше частота ядра, тем быстрее исполнится этот код, что приведёт к меньшей латентности. Из за ограничений теплового дизайна большинства ЦПУ, зачастую имеется некий компромисс между ростом значения тактовой частоты и общего числа ядер. Более высокое число ядер ЦПУ и более высокие частоты также имеют тенденцию размещаться в самых верхних позициях имеющейся структуры стоимости. Таким образом, было бы полезно понимать ваши требования к операциям ввода/ вывода и латентности при выборе наилучшего ЦПУ.

Был проведён небольшой эксперимент для нахождения самой подходящей тактовой частоты ЦПУ в сопоставлении с задержкой записи. Некая исполняющая Ceph рабочая станция имела выравниваемой вручную тактовую частоту своего ЦПУ с использованием регулятора пространства пользователя. Приводимые ниже результаты с очевидностью демонстрируют преимущество ЦПУ с высокими значениями таковых частот:

ЦПУ, МГц	Операций записи 4кБ	Средняя летентность (микросекунды)
1600	797	1250
2000	815	1222
2400	1161	857
2800	1227	812
3300	1320	755
4300	1548	644

Если важна низкая латентность и в особенности низкая латентность на запись, тогда двигайтесь в сторону наиболее высоких тактовых частот ЦПУ, которые вам доступны, в идеале, по крайней мере, 3ГГц. Может потребоваться некий компромисс в имеющих только SSD узлах в том, сколько ядер доступно и сколько SSD может поддерживать каждый узел. Для узлов с 12 шпиндельными дисками и журналами SSD четырёхядерные процессоры в одном разъёме могут быть исключительным выбором, поскольку они часто доступны с очень высокими тактовыми частотами и очень агрессивными стоимостями.

Когда латентность не очень важна, например, при объектных рабочих нагрузках, обратите внимание на процессоры начального уровня с хорошо сбалансированным числом ядер и тактовой частотой. {Прим. пер.: см. краткую таблицу рекомендованных к продаже цен Intel при заказе от 1000 штук для процессоров E5-2600 v4/v3 от 1 апреля 2016 в нашем переводе Книги рецептов Ceph Карана Сингха и более полную таблицу xls с выделенными жёлтым фоном ЦПУ, имеющими наилучшие поназатели стоимости исходя из требования 1ГГц на OSD.}

Другим подлежащим рассмотрению моментом относительно ЦПУ и материнской платы должен быть вопрос общего числа разъёмов ЦПУ. В архитектуре с двумя сокетами {Прим. пер.: а также 4/8/16/32} все оперативная память, контроллеры дисков, а также контроллеры сетевых интерфейсов (NIC, network interface controllers), совместно используются всеми разъёмами. Когда данные, требующиеся одному ЦПУ запрашиваются неким ресурсом, расположенным в другом сокете ЦПУ, они могут передаваться через шину взаимосвязи между такими двумя ЦПУ. Современные ЦПУ имеют высокоскоростное взаимодействие, однако они вносят некие штрафы в производительность и следует поразмыслить не стоит ли остановиться на архитектуре с одним сокетом. Имеется ряд вариантов, приводимых в разделе тонкой настройки по поводу того, как обойти некоторые из таких возможных штрафов производительности.

При выборе дисков для построения некоторого кластера Ceph, всегда имеется соблазн пойти с самыми большими дисками,которые только возможны, поскольку на бумаге они выглядят наилучшим образом. К сожалению, на практике, это зачастую не самый лучший выбор. Хотя диски и впечатляюще увеличились за последние 20 лет, их производительность выросла не так стремительно. Во первых, не обращайте внимания на значения MBps последовательного обмена, так как вы никогда не обнаружите их в корпоративных рабочих нагрузках. {Прим. пер.: с оговоркой случая восстановления и, частично, задач выполнения повторной балансировки}. Всегда имеется нечто, делающее все модели ввода/ вывода достаточно непоследовательными и даже достаточными для того чтобы они могли выглядеть случайными. Во вторых, запомните эти значения:

диски 7.2k = 70-80 4k IOPS

диски 10k = 120-150 4k IOPS

диски 15k = вам следует применять SSD

В качестве основного правила, если вы проектируете некий кластер, тогда предлагайте активные рабочие нагрузки вместо того чтобы выступать грудой неактивных/ архивных хранилищ. Выполняйте проект для необходимого значения IOPS (Input/Output Operations Per Second , числа операций ввода/ вывода в секунду), а не ёмкость. Если ваш кластер будет содержать шпиндельные диски большего размера при предназначении предоставлять хранение для некоторой активной рабочей нагрузки, увеличенное число дисков с меньшей ёмкостью обычно более предпочтительно чем применение дисков большего размера. С уменьшением стоимости SSD серьёзно задумайтесь о необходимости их применения в вашем кластере, либо в виде некоторого уровня кэширования, либо даже для всего кластера SSD. SSD уже сделали устаревшими диски 15k во всех нишах рабочих нагрузок; диски 10k скорее всего пройдут тот же путь к концу десятилетия. Скорее всего сцена хранения станет гонкой двух лошадок с медленными дисками большой ёмкости выполняющими роль массивного хранения и устройств на основе флеш- памяти для роли активного ввода/ вывода.

Стоит также подумать об использовании SSD либо для журнала вместе с файловым хранением Ceph, либо для хранения DB и WAL (write-ahead log, журнала отложенной записи) при применении BlueStore. Производительность файлового хранения впечатляюще улучшается при применении журналов SSD и не рекомендуется к использованию, если только данный кластер не спроектирован для применения с очень замороженными данными.

При выборе SSD для хранения DB BlueStore важно верно выбирать размер SSD с тем чтобы большая часть метаданных, а в идеале все они целиком, хранились именно в SSD. Официальные рекомендации для базы данных RocksDB составляют около 4% от общего размера HDD. На практике вы часто будете наблюдать именно такой уровень потребления в реальной жизни, причём 4% выводится из некой консервативной оценки. Для 10 ТБ дисков и ещё выше, что становится широко распространённым, выделение 400 ГБ SSD не является эффективным в стоимостном отношении. Если ваша RocksDB вырастает больше размера выделенного под неё SSD, тогда метаданные частично выкладываются в её HDD. Поэтому хотя SSD всё ещё задействован, запросы могут потребовать чтения метаданных с HDD, а это будет медленнее чем если бы метаданные хранились на SSD. В реальной практике в тестах с кластерами, применяющими рабочие нагрузки RBD, применение DB обычно находится в районе 0.5%. Глава 3, BlueStore этой книги будет содержать дополнительные подробности относительно хранения данных в RocksDB и требуемого для неё пространства.

Так как SSD применяемые для хранения DB BlueStore не применяются для хранения данных, их износостойкость на запись не столь критична как это было ранее, когда SSD применялись для файлового хранения. Вам также следует иметь в виду, что установленный по умолчанию уровень репликаций 3 будет означать, что любая запись операции ввода/ вывода клиента будет создавать по крайней мере троекратное увеличение ввода/ вывода на всех лежащих в основе дисках. При применении файлового хранения это значение может при некоторых обстоятельствах составлять около шестикратного увеличения записей из- за внутренних механизмов Ceph.

Поймите, что хотя Сeph делает возможным намного более быстрое восстановление с отказавшего диска, чем в случае RAID, поскольку в таком процессе восстановления примут участие все диски в данном кластере. Однако, диски большего размера всё ещё чинят препятствие, в особенности, когда сталкиваемся с необходимостью восстановления отказа некоторого узла. В некотором кластере, состоящем из десяти дисков по 1ТБ, причём каждый из них заполнен на 50%, в случае выхода из строя некоторого диска, всем оставшимся дискам пришлось бы восстанавливать 500ГБ данных между всеми, или, приблизительно по 55ГБ каждому. При средней скорости 20 Mbps, восстановление потребовало бы примерно 45 минут. Некий кластер с сотней 1ТБ дисков всё ещё потребует восстановления 500ГБ данных, однако это время, поскольку диск разделяется между 99 дисками, в теории для кластера с большим размером для восстановления в случае единичного отказа это потребовало бы примерно четырёх минут. В действительности, такое время восстановления будет выше, поскольку имеются задействованные в работе дополнительные механизмы, которые увеличивают время восстановления. В кластерах меньшего размера времена восстановления должны быть неким ключевым фактором при выборе ёмкости диска.

Сетевая среда является ключевым и зачастую не до конца осознанным компонентом в кластере Ceph; плохо спроектированная сетевая среда зачастую ведёт к целому ряду проблем, которые заявляют о себе своеобразным манером и делают крайне запутанным сеанс поиска неисправностей.

Необходимость сети 10G

Для построения кластера Ceph настоятельно рекомендуется сетевая среда 10G, хотя сетевые среды 1G будут работать, однако задержки будут подталкивать к пределам неприемлемости и ограничат вас в общем числе узлов, которое вы способны развернуть. Следует также обдумать восстановление; в случае отказа некоторого диска или узла, требуется перемещение больших объёмов данных по всему кластеру. Мало того, что некая сеть 1G не будет способна предоставить достаточной производительности для этого, однако это повлияет на обычные операции ввода/ вывода. В наихудших случаях это может привести к выходу по тайм- ауту OSD, что вызовет нестабильность кластера.

Как уже упоминалось, одним из основных преимуществ сетевой среды 10G является более низкая латентность. Достаточно часто некий кластер никогда не производит достаточного обмена чтобы целиком использовать всю пропускную способность 10G, однако, реализуется улучшение латентности, вне зависимости от общей загруженности в данном кластере. Среднее время пути для некоторого пакета 4K по сети 10G может занять примерно 90 микросекунд, а тот же самый 4K пакет по сетевой среде 1G потребует более 1 миллисекунды. В соответствующем разделе по тонкой настройке в данной книге мы изучим как задержки напрямую воздействуют на общую производительность некоторой системы хранения, в особенности при выполнении прямых или синхронных операций ввода/ вывода.

Позднее, когда стало доступным следующее поколение сетевого оборудования, причём с поддержкой начинающихся с 25G скоростей и достигающими 100G. Если вы реализуете некую новую сетевую среду когда развёртываете свой кластер Ceph, настоятельно рекомендуется подумать о развёртывании такого оборудования следующего поколения.

Если ваш узел OSD будет снабжён дуальным NIC, тщательно изучите сетевую архитектуру, которая позволит вам применять его в качестве активный/ активный как для передачи, так и для приёма. Будет расточительным оставить некое соединение 10G в каком бы то ни было пассивном состоянии и это поможет понизить задержки при загруженности.

Проектирование сетевой среды

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

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

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

Обычные сетевые среды в основном разрабатывались вдоль пути доступа Север- Юг, когда расположенные на Севере клиенты получают доступ к данным через имеющуюся сетевую среду к расположенным на Юге серверам. Если некому подключённому к к какому- то коммутатору доступа серверу требется взаимодействие с другим серевром, который в свою очередь подключён к другому коммутатору доступа, весь обмен должен будет направляться через имеющийся центральный коммутатор ядра. Благодаря такой схеме взаимодействия, все входящие в имеющийся уровень ядра уровни доступа и агрегации не были спроектированы для обработки массивного обмена внутри серверов, что великолепно для той среды, которую они предназначены поддерживать. Обмен сервера- с- сервером именуется обменов Восток- Запад и он становится преобладающим в большей части современных центров обработки данных, поскольку приложения становятся менее изолированными и требуют данных от множества прочих серверов.

Ceph создаёт большой обмен Восток- Запад, причём состоящий не только из внутреннего обмена кластера репликациями, но также и со стороны прочих серверов, потребляющих хранилище Ceph. В больших средах традиционная архитектура ядра, а также уровни агрегации и доступа может не справиться, так как большие объёмы обмена будут ожидаться подлежащими маршрутизации через имеющийся коммутатор ядра. Могут быть получены более быстрые коммутаторы, а также добавлены более быстрые или большее число восходящих связей, однако лежащая в основе проблема состоит в том, что вы попытаетесь исполнить горизонтальное масштабирование системы хранения в вертикально масштабируемой сетевой архитектуре. Приводимая ниже схема демонстрирует типичную сетевую архитектуру с уровнями Ядра, Агрегации и Доступа. Обычно было бы активным только одно соединение от уровня доступа к уровню агрегации.

Очень популярной в центрах обработки данных становится архитектура листья- ствол (leaf-spine). Этот подход полностью избавляется от традиционной модели и вместо этого заменяет её двумя уровнями коммутаторов: стволового уровня и уровня листьев. Имеющаяся концепция ядра состоит в том, что кажый коммутатор листа соединён с каждым из коммутаторов ствола с тем, чтобы каждый коммутатор листа имел только один прыжок (hop) к любому другому коммутатору листа. Это предоставляет согласованные латентность прыжков и пропускной способности. Ниже приведён пример некоторой топологии листьев и ствола. В зависимости от областей отказа вы можете пожелать наличие одного или множества коммутаторов листа на стойку для резервирования.

Именно на уровне листа подключаются все серверы и обычно он раздаёт большое число портов 10G и некое небольшое число 40G или более быстрых восходящих портов для соединения с имеющимся уровнем ствола.

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

Сетевые среды листьев и ствола обычно отступают от чистой топологии 2 уровня, при которой область 2 уровня завершается на таких коммутаторах листьев , а маршрутизация 3 уровня выполняется между всеми уровнями листев и ствола. Это рекомендуется осуществлять при помощи протоколов динамической маршрутизации, таких как BGP (Border Gateway Protocol, Протокола пограничного шлюза) или OSPF (Open Shortest Path First, Открытия первым кратчайшего маршрута) для установления полной маршрутизации по всей имеющейся инфраструктуре. Это привносит целый ряд преимуществ в сравнении с сетевыми средами 2 уровня. Стволовое дерево, которое обычно применяется в сетевых средах 2 уровня для предотвращения зацикливаний коммутаторов, выполняет работу блокируя некое восходящее соединение при использовании восходящих соединений 40G; это пустая трата огромных полос пропускания. При применении протоколов динамической маршрутизации с некоторой архитектурой 3 уровня можно применять маршрутизацию ECMP (Equal-cost multi-path, Множественных маршрутов с равной стоимостью) для справедливого распределения данных по всем восходящим связям для максимизации применения всей доступной полосы пропускания. В данном примере листовых коммутаторов, подключаемых к двум коммутаторам ствола через некие восходящие соединения 40G будет доступна полоса пропускания 80G любому коммутатору листа, причём вне зависимости от того где он расположен.

Некоторые сетевые архитектуры продвигают это даже ещё дальше, и вытесняют имеющиеся границы 3 уровня вниз до всех серверов, фактически исполняя такие протоколы маршрутизации на серверах с тем, чтобы ECMP можно было бы применять для упрощения использования обоих NIC в режиме активный/ активный. Такой подход именуется Маршрутизацией в самом хосте (Routing on the Host).

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

Области отработки отказа

Если в вашем кластере менее 10 узлов, скорее всего это не самый важный момент для вас.

При наследовании вертикально масштабированного хранилища всё оборудование ожидается имеющим 100% надёжность. Все компоненты являются резервированными и наличие отказа некоторого целого компонента, такого как системная плата или JBOD диск могут с большой вероятностью привести к выходу из строя. Вследствие этого не существует никакого реального понимания сколько таких отказов может выдержать работа данной системы, просто есть надежда что это не случится! В случае с Ceph основное предположение в том, что полный отказ некоторого отдела вашей инфраструктуры, будь то некий диск, узел, или даже стойка, должны рассматриваться как нечто обычное и не должно приводить кластер в нерабочее состояние.

Давайте возьмём два кластера, каждый из которых наполнен 240 дисками. Кластер A представлен дисками узлов 20x12; Кластер B состоит из дисков узлов 4x60. Теперь допустим сценарий, при котором по какой- либо причине некий узел OSD Ceph отключается. Это может быть из за запланированного обслуживания или в случае неожиданного отказа, однако этот узел сейчас отключён и никакие данные на нём недоступны. Ceph разработан для маскирования подобной ситуации и даже проведёт восстановление пока не настроит полный доступ к данным.

В данном случае, кластер A имеет утраченными 5% наших дисков и при событии некоторой постоянной потери должен будет восстановить 72ТБ данных. Кластер B потерял 25% своих дисков и должен будет перестроить 360ТБ. В последнем случае это сильно повлияло бы на общую производительность всего кластера и при варианте применения перестроения данных такой период деградации производительности мог бы продолжаться на протяжении многих дней.

Даже если будет принято решение переопределить автоматическое лечение и оставить Ceph в деградировавшем состоянии пока вы не исправите или не выполните работы по обслуживанию некого узла, в примере с 4x60 диском перевод узла в автономный режим также снизит производительность имеющегося ввода/ вывода вашего кластера на 25%, приводящего к нежелательному воздействию на приложения клиентов

Ясно что в кластера меньшего размера такие узлы с очень высокой плотностью не очень хорошая мысль. Некий кластер Ceph из 10 узлов, скорее всего, самый минимальный размер в случае, когда вы желаете уменьшить воздействие отказа узла и поэтому в случае с JBOD из 60 дисков вам нужен некий кластер, который, как минимум, измеряется петабайтами.

Стоимость

Часто упоминаемой причиной желания работать с большими плотными узлами является попытка снизить общую стоимость всего покупаемого оборудования. Зачастую это обманчивая экономия, так как плотные узлы имеют тенденцию нуждаться в комплектующих премиального класса, что обычно заканчивается большими стоимостями ГБ в сравнении с вариантом менее плотных узлов.

Например, узел с 12 дисками может потребовать всего одного четырёх ядерного процессора для предоставления достаточного ресурса ЦПУ для всех OSD. Некое шасси с 60 отсеками может требовать двойных 10 ядерных процессоров, или даже более, которые стоят намного дороже за предоставляемый ГГц. Вам может даже понадобиться больше DIMM (Dual In-line Memory Modules, Модулей памяти с двухрядным расположением микросхем), которые потребуют NIC 10G премиум уровня, причём возможно с большим их числом, или даже более быстрые NIC.

Большую часть общей стоимости от всего оборудования будут составлять стоимости ЦПУ, оперативной памяти, сетевого оборудования и дисков. Как мы уже видели, Все эт ресурсы оборудования требуют линейной масштабирования в соответствии с общим числом и размером дисков. Единственная область в которой узлы большего размера могут иметь некоторое преимущество состоит в требовании меньшего числа материнских плат и источников питания, которые не составляют некую большую часть общей стоимости. {Прим. пер.: следует отметить, что автор упускает такие моменты, как стоимость аренды 1U в стойке, или возможность удалённого управления через ВМС, что уже давно является неотъемлемой частью оборудования, гордо носящего название серверного.}

При обзоре кластеров только с SSD, более высокая производительность SSD диктует применение более мощных ЦПУ и требований значительного увеличения полосы пропускания. Несомненно будет плохой мыслью развернуть отдельный узел с 60 SSD, поскольку требуемые ресурсы ЦПУ будут либо просто невозможными, либо вероятно с запретительным уровнем стоимости. Применение серверов 1U и 2U с 10 или 24 отсеками под диски, скорее всего, обеспечит оптимальное соотношение затрат и производительности в зависимости от варианта применения данного кластера.

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

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

Чтобы иметь полную уверенность что ваша реализация Ceph будет успешной, имеется ряд правил, которым вы должны следовать:

Как мы уже обсуждали, Ceph не всегда является правильным выбором для всех требований хранения. Будем надеяться, данная глава снабдила вас достаточными знаниями чтобы иметь возможность помочь вам определить свои требования и их соответствие возможностям Ceph. Надеюсь также, что Ceph хорошо подходит для вашего варианта использования и вы можете продолжить данный проект.

Необходимо принять во внимание все требования вашего проекта, включая следующие:

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

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

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

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

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

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

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

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

Для проверки выбранной архитектуры следует развернуть некий кластер PoC (proof of concept, Подтверждения концепции) и определить любые проблемы ранее чем начнётся процесс полномасштабного приобретения оборудования. Это должно рассматриваться в качестве момента принятия решения в данном проекте; не бойтесь пересматривать цели или начинать проект с чистого листа еслт сталкиваетесь с серьёзными проблемами. Если у вас имеется оборудование аналогичной спецификации, будет прекрасно воспользоваться им для проверки концепции, однако основная цель должна состоять в том, чтоб вы попытались проверить то оборудование, которое по возможности максимально похоже на то, которое вы намереваетесь применять при построении промышленного кластера с тем, чтобы иметь возможность полностью проверить всю архитектуру.

Помимо проверки на устойчивость, данный кластер PoC также должен применяться для прогноза того, что все поставленные вами цели будут им выполнены. Хотя может оказаться сложно напрямую реплицировать требования к рабочей нагрузке во время PoC, необходимо приложить усилия чтобы попытаться и сделать такие тесты максимально соответствующими предполагаемой рабочей нагрузке. Этап проверки концепции также правильное время для того, чтобы вы укрепили свои навыки Ceph, освоили повседневную практику работы и проверили все свойства. Это будет полезно в дальнейшем. Вам также следует воспользоваться возможностью быть в особенности жестоким, насколько это возможно, по отношению к своему кластеру PoC. Произвольно вынимайте диски, отключайте узлы и разъединяйте сетевые кабели. Если он спроектирован правильно, Ceph должен быть способен перенести все эти издевательства. Выполнение таких проверок сейчас придаст вам уверенности в последующей работоспособности Ceph в большем масштабе если такие события в нём будут случаться, а также поможет вам понять как их устранять в случае возникновения.

При развёртывании вашего кластера внимание должно быть сосредоточено на понимании самого процесса вместо простого следования за примерами. Это снабдит вас лучшим пониманием различных составных частей, которые выстраивают Ceph, а если вы столкнётесь в процессе развёртывания и работы с какими- либо ошибками, вы будете лучше находить их разрешение. Следующая глава данной книги снабдит вас более подробными сведениями по развёртыванию Ceph, включая применение инструментария координации (orchestration).

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

Уровень репликаций пула RADOS должен быть оставлен со значением, определённым по умолчанию равным 3, а минимальный уровень репликаций должен равняться 2. Это соответствует имеющимся в пуле переменным size и min_size соответственно. Пока вы не получите и лучшего представления о них самих, и причин воздействия на них в сторону уменьшения, будет неразумным изменять их. Размер репликаций определяет сколько копий данных будет храниться в данном кластере и все последствия его снижения должны быть очевидны в смысле защиты от утраты данных. Менее понятно воздействие от min_size в отношении утраты данных и наличием причины для такового. Аналогичным образом следует настраивать и пулы удаляющего кодирования с тем, чтобы имелось как минимум два фрагмента для восстановления. Неким образцом может служить k=4 m=2; это предоставит такую же устойчивость к сбоям как и пулы с тремя репликациями, но при удвоении потребляемой ёмкости.

Сама переменная min_size управляет тем, сколько копий в данном кластере должно быть записано для получения подтверждения от отложенной записи клиентом. Значение 2 в min_size означает, что данный кластер должен иметь возможность записать две копии данных; это может означать в случае сценария требовательного в отношении к деградации, что операции записи блокируются если данная группа размещений (PG) имеет только одну остающуюся копию и не продолжит работу пока данная PG не восстановится чтобы иметь две копии данного объекта. Именно это является причиной того, то может иметься желание понижения значения min_size до 1 , чтобы в данном случае операции кластера всё ещё могли продолжаться и если доступность более важна чем согласованность, тогда это может стать решением. Однако при min_size установленным в 1 , данные могут быть записаны только если имеется один OSD и нет никакой гарантии, что общее число желаемых копий будет восстановлено когда либо вскорости. На протяжении этого времени любые отказы компонентов скорее всего будут иметь результатом утрату данных, записанных в таком состоянии деградации. В случае когда суммарное время простоя является нежелательным, утрата данных обычно хуже и именно эти два параметра, скорее всего, будут иметь одно из самых основных последствий для утраты данных.

Единственный сценарий, когда min_size устанавливается в значение 1 на постоянной основе, это когда в кластере с крайне малыми размерами на самом деле не хватает OSD, хотя при таком масштабе спорен сам по себе выбор Ceph для подходящей платформы хранения. {Прим. пер.: подумайте о ZFS!}

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

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

В данной главе вы изучили все необходимые этапы, которые позволят вам успешно спланировать и реализовать некий проект Ceph. Вы изучили все возможные варианты оборудования, как они соотносятся с требованиями Ceph, и как они могут воздействовать и на производительность Ceph, и на его надёжность. Наконец, мы ознакомили вас о той важности всех процессов и процедур, которые должны быть рассмотрены в своё время чтобы гарантировать жизнеспособность рабочей среды для вашего кластера Ceph.

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