об авторе
Ван Шеян, инженер американского видеосайта hulu, окончила Пекинский технологический институт по специальности «компьютерные науки» и в настоящее время работает над инфраструктурой больших данных. Персональная колонка Zhihu «Сводка больших данных SRE»: http://dwz.cn/7ygSgc
Последние два года моя основная работа была в стеке Hadoop, а недавно мне посчастливилось соприкоснуться с Ceph. Я думаю, что это очень удачная вещь.Это дает мне возможность испытать еще одно масштабное распределенное решение для хранения.Я могу сравнить преимущества и недостатки HDFS и Ceph, двух почти совершенно разных систем хранения, и какие сценарии подходят для них. . . .
Для распределенного хранилища, особенно распределенного хранилища с открытым исходным кодом, с точки зрения SRE, я думаю, что это в основном решает следующие проблемы для коммерческих компаний:
-
Масштабируемость для удовлетворения огромных требований к хранению данных, вызванных ростом бизнеса;
-
Дешевле, чем коммерческое хранение, что значительно снижает затраты;
-
Стабильный, управляемый, простой в эксплуатации и обслуживании.
Короче говоря, цель такова: простой в использовании, дешевый и стабильный. Но реальность выглядит не так уж хорошо...
Я думаю, что эта статья будет начинаться с этих трех фундаментальных ценностей, анализировать мой опыт эксплуатации и обслуживания Ceph и сравнивать централизованные распределенные системы хранения, такие как HDFS, чтобы говорить об этом по горизонтали.
Ceph претендует на бесконечную масштабируемость, потому что он основан на алгоритме CRUSH и не имеет центрального узла. На самом деле Ceph действительно может расширяться бесконечно, но процесс бесконечного расширения Ceph не совсем красив.
Во-первых, давайте разберемся с процессом написания Ceph. Чтобы записать новый объект в Ceph, ему необходимо пройти заранее заданную квоту Фрагментация хэшей уровня PG, а затем PG, а затем хеш, сформированный OSD всех физических машин в кластере, попадает на физический диск.
Поэтому все объекты Ceph сначала предварительно хэшируются в фиксированное количество сегментов (PG), а затем выбираются для попадания на конкретные машинные диски в соответствии с общей физической архитектурой кластера, crushmap.
Как это влияет на масштабирование?
1 Степень детализации расширения
Мое определение детализации масштабирования таково: сколько машин можно масштабировать одновременно.
На практике расширение емкости Ceph ограничено "областью сбоя", и одновременно может быть расширен только один "домен сбоя".
Домен сбоя: уровень изоляции реплики, то есть данные одной и той же реплики размещаются на разных дисках/машинах/стойках/компьютерных залах.
Концепция толерантности неисправностей во многих программах хранения, включая HDF. Почему Ceph будет повлиять? Поскольку CePh не имеет централизованного узла метаданных, это заставляет стратегию размещения данных по затронутую.
Стратегия размещения данных, то есть на какой машине и на каком жестком диске размещать копию данных.
Централизованные, такие как HDFS, будут записывать каждый файл, место хранения каждого блока данных ниже. Эта позиция не будет часто меняться и будет меняться только тогда, когда 1. файл создается заново, 2. балансировщик перебалансируется, 3. жесткий диск выходит из строя, и центральный узел перемещает данные на поврежденном оборудовании.
А Ceph из-за децентрализации заставляет положение PG, в котором хранятся данные, изменяться в соответствии с изменением карты раздавливания. Когда приходят новые машины и жесткие диски, необходимо рассчитать новые места для некоторых затронутых PG. Технология, основанная на последовательном хешировании, также сталкивается с той же проблемой при масштабировании.
Следовательно, расширение Ceph требует настройки PG. Из-за этой настройки Ceph подвержен "областям сбоя".
Например: есть PG с 3-мя копиями, а кластер Ceph имеет конфигурацию, которая нужна PG для предоставления нормальных услуг внешнему миру, а полных копий минимум 2. Когда отказоустойчивым доменом пула данных является хост, и одновременно расширяются две машины, некоторые PG могут отображать две из трех копий на две новые машины. И эти 2 копии все новые копии, и ни одна из них не имеет полных и актуальных данных. Оставшаяся одна копия не может соответствовать требованию, чтобы старая машина имела по крайней мере две полные копии, поэтому она не может обеспечить нормальные услуги чтения и записи.
Это приведет к тому, что все объекты в этой группе размещения перестанут обслуживаться извне.
Как администратор, конечно, вы можете уменьшить конфигурацию и уменьшить min_size пула данных до 1. Но эта конфигурация, даже при нормальных обстоятельствах, может привести к потере данных из-за сбоя диска, поэтому она обычно не устанавливается таким образом.
При расширении безопасно ли расширять только одну машину за раз?
Это гарантирует, что все группы размещения будут иметь как минимум 2 полные копии на старой машине. Однако, даже если машина расширяется, она по-прежнему сталкивается с экстремальной ситуацией, когда жесткий диск старой машины выходит из строя во время расширения, что приводит к тому, что полная копия PG снова падает до 1.
Хотя PG может быть не в состоянии обслуживать, проблем с сохранением данных нет. В отечественном облаке AT надежность услуги не особенно высока и достигает 3 9 или 4 9, например, постоянства. Хотя я не уверен, использует ли хранилище объектов в этих двух больших облаках Ceph, если оно основано на алгоритме CRUSH, или хранилище объектов, реализованное с помощью децентрализованных технологий, таких как согласованное хеширование, оно должно иметь некоторые данные, временно недоступные.
Оставим в стороне самый крайний случай, предполагающий отсутствие повреждения диска на данный момент, когда машина добавляется в качестве «домена сбоя» при расширении. Так есть ли способ улучшить детализацию расширения?
Способ сделать это состоит в том, чтобы установить более высокий уровень "области сбоя", такой как Rack, когда вы начинаете планировать свой кластер Ceph. Может быть реальной стойкой или логической стойкой, если нет. При расширении таким образом может быть расширен логический «отказоустойчивый домен», что может нарушить ограничение расширения одной машины и расширить всю Стойку, как минимум несколько машин.
Советы:Здесь я не говорил о том, почему небольшой масштабирующий гранулярность - это плохое. Фактически, во многих компаниях среднесуточный рост данных, вероятно, будет больше, чем емкость хранения машины. Это приведет к смущению ситуации, что скорость расширения не может не отставать от скорости записи. Это не небольшой вред на более позднем этапе для кластера, который не спроектирован хорошо в начале, и карта быстро развернута и возведена.
2 Изменения в карте раздавливания во время расширения
Ceph размещает физическое местоположение PG в соответствии с разбивочной картой.Если другой жесткий диск выйдет из строя во время расширения, разбивочная карта Ceph изменится, и Ceph снова повторно хэширует PG.Многие местоположения PG будут пересчитаны заново. Если вам не повезло, вполне вероятно, что процесс расширения машины будет продолжаться в течение длительного времени, прежде чем вернуться в стабильное состояние.
Ребалансировка Ceph, вызванная этим изменением crushmap, является головной болью не только для большого кластера хранения в любое время, не только во время расширения емкости. При построении нового кластера жесткие диски относительно новые, поэтому процент отказов невелик. Но в большом кластере хранения, работающем 2-3 года, неисправные диски действительно частое явление, для кластера масштаба 1000 нормально терять 2-3 диска в день. Карта раздавливания часто меняется, что очень сильно влияет на внутреннюю нестабильность Ceph. Вслед за этим общий IO может упасть (дисковый IO занят повторными перебалансировками) или даже некоторые данные временно недоступны.
Так что в целом расширение Ceph немного неприятно. Ceph обеспечивает неограниченную масштабируемость, но процесс масштабирования не является гладким и полностью контролируемым. Дизайн crushmap обеспечивает хороший эффект децентрализации, но он также закапывает яму для нестабильности после того, как кластер станет большим.
В отличие от HDFS с централизованными метаданными, здесь почти нет предела расширению, и вы можете расширяться с радостью. Перемещение и повторная балансировка старых данных будут выполняться отдельной задачей, и обработка также очень эффективна. Он использует пару полных узлов и пустых узлов для перемещения достаточного количества данных из старого узла для заполнения новой машины. Централизованные метаданные становятся преимуществом при масштабировании и ребалансировке.
3 После того, как расширение достигает определенного уровня, необходимо скорректировать количество PG.
Как показано на блок-схеме записи данных Ceph выше, минимальной единицей размещения объекта Ceph является группа размещения, и группа размещения будет размещена на жестком диске.Теоретически, чем больше группа размещения, тем лучше. Поскольку таким образом случайность сегментирования данных лучше, она может лучше покрыть проблему чрезмерного отклонения емкости одного диска, вызванного псевдослучайностью. Но количество PG на самом деле не лучше, оно ограничено оборудованием, таким как процессор, память, сеть. Поэтому при планировании числа PG мы не будем его слепо увеличивать, да и вообще сообщество рекомендует 200pg/osd.
Предположим, что теперь у нас есть 10 машин, на каждом жестком диске всего 10 дисков, имеется 1024 группы размещения, и все группы размещения являются отдельными копиями, тогда на каждом диске будет храниться 100 групп размещения. В настоящее время эта настройка очень полезна, но когда мы расширим кластер до 1000 машин, на каждый жесткий диск будет помещена только одна PG, что приведет к усилению дисбаланса, вызванного псевдослучайным распределением. Поэтому админ сталкивается с настройкой количества PG, что приносит проблемы.
Настройка PG в основном означает, что весь кластер войдет в серьезное ненормальное состояние. Почти 50% объектов, в которых задействованы настроенные ГУ, нуждаются в физическом перемещении, что может привести к серьезному падению качества обслуживания.
Хотя корректировка PG не является частым событием, в крупномасштабном хранилище, с развитием, неизбежно пройти это большое испытание.
Под сравнением с коммерческими хранилищами мы подразумеваем сравнение с производителями аппаратных и программных решений для хранения, такими как EMC и IBM, или облачными решениями, такими как Aliyun и AWS.
Самостоятельное строительство компьютерного зала, конечно, дешевле с точки зрения цены за единицу оборудования, но вам необходимо учитывать общую стоимость, в том числе: 1. стоимость оборудования, 2. затраты на самоокупаемую эксплуатацию и обслуживающий персонал, 3. постепенное сближение качества обслуживания. от общего к лучшему.
Я не буду говорить о метафизической проблеме человеческой стоимости. Эта статья говорит только о том, что интересно о Ceph в оборудовании. Чтобы быть разумным, если вы построете собственную компьютерную комнату, стоимость оборудования должна быть, несомненно, она несомненно, так что такое так особенное в CePh?
Проблема в том, что кластер надежно используется.
Надежное использование кластера, то есть весь кластер не может предоставлять внешние сервисы, когда емкость достигает определенного уровня, или не может поддерживать сервисы высокой доступности.
Например, может ли флэш-память мобильного телефона/жесткий диск компьютера нормально работать на 99%? Конечно, потому что это локальное хранилище. Для облачных решений такой проблемы естественно нет.
Для коммерческих решений хранения, таких как распределенная файловая система Isilon от EMC, емкость хранилища достигает даже 98-99% и все еще может предоставлять внешние услуги.
Для HDFS ниже 95% хранилище также может хорошо предоставлять внешние сервисы. Задание Hadoop, работающее в HDFS, зависнет, поскольку оно не может выполнять локальную запись.
Для Ceph он не очень хорошо работает в этой области. Как показывает опыт, после того, как общая загрузка кластера достигает 70%, возможен переход в нестабильное состояние.
Почему это? Проблема заключается в компромиссе, вызванном децентрализацией.
Ceph — это децентрализованное распределенное решение, и метаданные объектов распределяются на каждой физической машине. Таким образом, все объекты размещаются на каждом диске "псевдослучайно". Псевдослучайность не может гарантировать полностью равномерное распределение всех дисков, и не может снизить вероятность попадания множества крупных объектов на один диск одновременно (я так понимаю, что добавление слоя PG и создание большего количества реплик PG может уменьшить дисперсию диск), поэтому всегда есть диски с более высоким уровнем использования.
Когда общее использование кластера невелико, проблем нет. После того, как уровень использования достигает 70%, администраторы должны вмешаться. Из-за большой дисперсии он, вероятно, достигнет красной линии в 95%. Администратор начинает уменьшать перевес дисков с большой емкостью, но если какие-то диски заполнены до того, как будет скорректирован перевес этой партии дисков, то администратор должен быть принудительно перезапущен Ceph до достижения стабильного состояния. перевзвешены слишком высоко. Это приводит к еще одному изменению в карте раздавливания, из-за чего Ceph все дальше и дальше уходит от своего стабильного состояния. Если расширение не будет своевременным в это время, будет еще хуже.
Более того, промежуточное состояние предыдущей crushmap также приведет к тому, что некоторые PG будут мигрированы наполовину, и эти «неполные» PG не будут удалены сразу, что увеличивает нагрузку на и без того тесное дисковое пространство.
Некоторым студентам может быть любопытно, почему Ceph недоступен, когда диск заполнен. Ceph действительно разработан таким образом, потому что Ceph не может гарантировать, попадет ли новый объект на пустой диск, а не на полный диск, поэтому Ceph предпочитает отказываться от обслуживания, когда диск заполнен.
После того, как я проконсультировался с некоторыми коллегами и коллегами по отрасли, практически каждый кластер Ceph готов к расширению, когда он достигает 50%-го использования. Это на самом деле довольно дорого, потому что ресурсы хранения большого количества машин должны быть освобождены. И чем больше размер кластера в будущем, тем больше будет эффект вакансий, а значит больше выброшенных денег/счетов за электроэнергию.
Во многих традиционных централизованных распределенных системах хранения, поскольку мастер-узел может выбрать для записи относительно простаивающую машину, нет проблемы, что некоторые диски заполнены и весь кластер не может быть записан. Это также имеет место, так что общая запись может достигать 95%, а доступность по-прежнему сохраняется.
Я действительно не учитывал потери затрат на этот эффект, но, по крайней мере, он выглядит немного несовершенным.
Например, когда я оцениваю, что у меня есть 50 ТБ дискового пространства, мне нужно 300 физических машин, фактически мне нужно заранее купить еще 200-300 физических машин.
Поэтому Ceph не обязательно дешев, а децентрализованное распределенное хранилище не так красиво.
Однако вред централизации кажется бесспорным вопросом (проблема одной точки, проблема масштабируемости центрального узла и т. д.), поэтому на самом деле в распределении нет серебряной пули, есть только компромисс.
Другой способ - расширить кластер Ceph в соответствии со всем пулом.Когда пул заполнен, он не будет расширен.При открытии нового пула новые объекты могут быть записаны только в новый пул.Объекты старого пула можно удалить и прочитать. На первый взгляд, это отличное решение, но если подумать, то кажется, что оно ничем не отличается от федерации HDFS, подбазы данных и подтаблицы MySQL и фронтенда big Hash.
Это не "бесконечное расширение", и необходимо писать передний слой маршрутизации.
Эта стабильная и хорошая работа и обслуживание в основном зависят от жесткой силы команды. Знакомство с программным обеспечением с открытым исходным кодом и опыт действительно имеют большое значение.
В то же время на это влияет и качество документации в open source сообществе. Сообщество открытого исходного кода Ceph все еще хорошее.После того, как Red Hat приобрела Ceph и доминировала над ним, оно реорганизовало документацию Ceph версии Red Hat.Я думаю, что это более логично читать.
Также важно накапливать собственную эксплуатационную документацию внутри компании. Новичок, скорее всего, сделает много ошибок, которые приведут к несчастным случаям. Но для компаний, если вы наступите на яму один раз, постарайтесь не наступать на нее второй раз. Это создало некоторые проблемы для управления накоплением технологий компании, управлением технической документацией и основным управлением утечкой мозгов.
Я столкнулся со сложной проблемой в эксплуатации и обслуживании Ceph. То есть после того, как кластер Ceph достигает 80%, диск часто становится заполненным, и тогда администратор вмешается и уменьшит перевес старшего диска. Прежде чем использование этого диска прекратится, другие диски будут заполнены, и администратору придется снова вмешаться и отрегулировать повторное взвешивание.С тех пор Ceph никогда не входил в стабильное состояние, и администратор также должен все время следить за кластером. Это приводит к огромным инвестициям в эксплуатацию и техническое обслуживание, поэтому следует избегать подобных вещей, что наносит большой вред моральному духу эксплуатационного и обслуживающего персонала.
Итак, следует ли заблаговременно предупреждать о возможности инициировать процесс закупок?
Но это приводит к тому, что выпускает вопрос об истощении ресурсов.
Кроме того, объекты Ceph не имеют метаданных, таких как last_access_time, поэтому различие холодных/горячих объектов Ceph требует вторичной разработки и дополнительной работы. После того, как кластер станет большим, способы очистки ненужных данных и архивации холодных данных также вызовут трудности.
1. Ceph имеет возможность бесконечно расширяться, но это требует хорошего начального планирования, а процесс расширения не идеален. Централизация создала верхний предел расширения емкости, который является физическим пределом одного главного узла, и создала теоретическую основу для бесконечного расширения емкости.Однако при фактическом расширении емкости качество обслуживания будет сильно ограничено.
2. Ceph — это пустая трата оборудования, и при расчете стоимости следует учитывать больше.
3. Децентрализованная структура Ceph сама по себе приносит в жертву большое количество метаданных, таких как время последнего доступа, что оказывает давление на будущее управление данными и требует более сильной команды для эксплуатации, обслуживания и вторичной разработки. Накопление опыта эксплуатации и обслуживания, а также создание групп по эксплуатации и обслуживанию — основа освоения распределенного хранилища с открытым исходным кодом. По мере того, как противник становится все сильнее и сильнее с течением времени, команда по эксплуатации и техническому обслуживанию должна становиться все лучше и лучше, чтобы производственные отношения могли соответствовать требованиям производительности.
4. Сама по себе технология не является абсолютно хорошей или плохой, разные технологии используются для решения разных задач. Но в сценариях технологии хороши и плохи. Потому что в сценарии у вас есть позиция, и у вас есть приоритет решаемых проблем, и вы сможете выбрать наиболее подходящую технологию в соответствии с приоритетом.
Недавний горячий текст
Научит вас некоторым методам вторжения и защиты базы данных MySQL.
Как Trafodion с открытым исходным кодом реализует интеграцию транзакций и анализа?
Архитектура кеша Weibo рассчитана на десятки миллиардов ежедневных посещений
Последние действия
Саммит DAMS China по управлению активами данных, 2018 г.