Comments 103
Бэкап этих СУБД делают другими способами — репликация на другие ноды и снэпшоты на СХД.
Kонсистентность является важнейшим понятием теории управления данными (data management) и входит в четвёрку ACID (Atomicity, Consistency, Isolation, и Durability) — Атомарность, Консистентность, Замкнутость и Живучесть (стойкость).
В СУБД больших размеров за время резервного копирования происходят записи данных и часть некоторые транзакции могут не попасть на конкретную ноду из-за того, что она в режиме резервного копирования находится.
Как ЭТО бэкапить — очень не простой вопрос. Скорей всего на уровне СХД и разнос в разные датацентры.
To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.
Узлы кластера кассандры равноценны, и клиенты могут соединятся с любым из них, как для записи, так и для чтения. Запросы проходят стадию координации, во время которой, выяснив при помощи ключа и разметчика на каких узлах должны располагаться данные, сервер посылает запросы к этим узлам.
Для каждого запроса, как на чтение, так и на запись, есть возможность задать уровень согласованности данных.
Только не защищает от логических ошибок такая организация бэкапа.
А про mongodump
IMPORTANT
To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.
1 — По поводу томов по 1-2 тб, тут как мне кажется нужно привязываться к физическим дискам, а не к размеру тома. Ну и главный вопрос о том сколько хостов работают с этим томом, должно быть несколько томов на разных физических дисках и желательно чтобы том не выходил за приделы одной корзины, если говорить про классическую схд =)
2 — Через версии прошивок тоже прыгать не очень хорошо, у меня так отвалились все луны когда я прыгнул через версию =( (HP MSA p2000 G3), но конец был с хепиендом и без потери данных.
Как я написал ниже рекомендации по поводу размера томов я даю из других сладкий.
2. Именно поэтому работа заняли столько времени — мы не прыгали через версии, а обновлялись последовательно.
Кстати, одна странность нам сыграла на руку — администратор заказчика во время действовавшей поддержки вендора выкачивал прошивки, но почему-то опасался обновляться.
Объясните популярно по поводу 1-2 Тб томов, пожалуйста. Если у меня кластер виртуализации, то чем плох Один Большой Кластерный Том? Что делать с 10 томами по 2 Тб?
Тут как всегда несколько факторов:
- СХД — если она нормально работает и рост нагрузки не планируется — менять ничего не стоит. Если одно из этих условий не выполняется — нужно смотреть подробнее. Если в кратце — несколько лунов позволят распараллелить запросы. Но это не объём комментария.
- Виртуализация — несколько мелких ФС проверяться быстрее, чем одна большая.
- Если вам нужен именно один большой том и никак иначе — нудно выбирать СХД с учётом этого, но я не очень представляю задачу, когда нужен один том на 100500 ТБ
Не совсем в тему, но вспомнилась локальная шутка:
После всех грехов с EVA мы получили в догонку 3PAR.
http://www.oracle.com/technetwork/database/features/availability/br-overview-097160.html
Первая и самая главная заповедь.
Один том на ~12 Тб не будет нормально работать ни на одной классической СХД.
DDP на NetApp E-series — будет.
Да на самом деле много где будут работать и не жужжать. Совет из тематики "обжёгшись на молоке, дуешь и на воду". В целом странно видеть в наше время подобные рекомендации. Как и про "не выходить за пределы одной корзины" на классических СХД.
С таким же успехом можно рекомендовать использовать локальные диски, а все диски, что размером 2Tb и больше, разбивать на разделы по 1Tb. Это уж точно сбережет ваши данные.
Из опыта работы с СХД я для себя сделал вывод — лучше объединить несколько томов средствами ОС. Если можно почти безболезненно распараллелить запросы — зачем ставить их в одну очередь?
Каким образом вы объедините несколько томов например в VMware кластере, не увеличивая при этом размер VMFS? Или вы предлагаете использовать софтовый рэйд уже внутри виртуальной машины? Для примера в Win server можно использовать софтовый RAID, вот только на моей практике ничего кроме Raid1. Иначе резко повышаются шансы потерять все. А Raid1 не позволяет увеличить размер тома.
При этом, в текущей реальности, размер тома внутри одной виртуальной машины более 1TB далеко не экзотика. А количество одновременных запросов на один логический том вполне поддается тюнингу почти во всех современных OS. (Для примера https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1268).
Я работаю с кластерами VMware и СХД с 2008 года. Из СХД последовательно были HP MSA2000, EMC Clariion CX4, VNX5300. Мой опыт показывает, что если не пускать все на самотек и поддерживать в актуальном состоянии софт и версии прошивок железа, то никаких проблем с томами размером более 2TB нет. При том что подавляющее большинство обновлений выполняется без остановки ввода\вывода.
В конце статьи я написал рекомендации, которые стоит учитывать, не правила. Каждую конкретную конфигурацию нужно внимательно рассматривать и планировать.
Спасибо за ваши замечания.
за соизмеримую сумму можно купить HP MSA с дисками…
Например, однажды у одного заказчика в течение полугода из-за ошибки в микрокоде было два останова — в первый раз вышел из строя HighEnd массив одной «японской» компании, в другой раз HighEnd сервер большой компании с голубым логотипом.
Хорошо, что у них две географически разнесённые площадки и простой был минимален или его не было совсем, но факт остаётся фактом.
К сожалению, серебряной пули не существует и наши проектировщики каждый конкретный случай всегда рассматривают отдельно, на сколько мне известно.
В вашей ситуации я бы выбрал shared datastore. На чем он будет лежать — нужно смотреть подробнее.
Нюансов много — latency, iops, стоимость оборудования и поддержки, требования ко времени простоя и срокам ремонта, наличие компетенции внутри компании.
Последний момент не менее важен. Представьте себе, что вы всю жизнь работали с Solaris и тут боевую систему за которую вы отвечаете переводят на AIX. Я такое видел — перестроиться сложно и это вызовет много проблем просто из-за того, что "как это не умеет?"
Если у вас есть хорошая компетенция по vSAN — ставьте его, но перед этим все равно сравните с классическими СХД.
Мой задачей было рассказать. Выводы читатель волен делать сам.
Для больших данных есть же другие технологии.
Согласен с выводом 1. Том более 2 ТБ. под VMware.Удачи при ремонте. Накроется — молитесь.
А есть ли какие то зависимости от размера дисков? например в СХД 12 дисков по 1,2 ТБ.
как из правильно собирать в RAID? Размер тома не должен превышать 2ТБ?
то есть надо делать 4 LUN по 3 диска в RAID5?
Или еще вариант 12 SSD по 400 гигабайт. делаем 2 LUN по 6 дисков RAID5?
И есть ли какая — то информация на эту тему?
И связанно ли это с тем что меньший массив дисков проще собрать обратно?
А рекомендации по размерам томов даются из следующих соображений:
1. Длительная проверка ФС. ФС поменьше можно проверять параллельно.
2. У LUN-ов есть параметр «очередь команд», если много хостов (например, VMware-кластер) одновременно будут обращаться к одному тому — производительность будет заметно ниже, варианта с несколькими datastore-ами поменьше. (особенно это хорошо заметно на HDS AMS и HUS).
RAID5 Еще используют для больших объемов? Встречал информацию, что восстановление полетевшего диска весьма накладно получается по временным затратам, а это все тормоза системы сутками.
СХД была спроектирована некорректно. Один том на ~12 Тб не будет нормально работать ни на одной классической СХД. Всегда разбивайте общую ёмкость на тома порядка 1-2 Тб. Да, будет меньше полезной ёмкости, но зато будет гораздо меньше шансов открыть заявку «у нас всё тормозит».
Заявление громкое, эмоциональное, но, к сожалению, не очень информативное.
А можно обоснование посерьёзнее? С примерами, конкретикой и ссылками на вендорские документы типа Best Practice. Буду крайне признателен.
Не дождетесь :). Ибо вся суть в вашей первой фразе.
К великому своему сожалению, ближайшие 2-3 дня не будет времени на подготовку такого основательного ответа. Но на скорую руку ниже примеры. Я рассматриваю случай когда много хостов работают с одним LUN.
Один из примеров — массивы HDS midrange (до последнего поколения VSP G точно). У них есть ограничение очереди команд на LUN равное 32, соответственно, при 8 хостах работающих с одним луном очередь команд на лун у каждого хоста должна быть не больше 4, а это маловато, согласитесь.
У EMC VNX с этим получше — queue depth per LUN = 224, но упереться в этот лимит некоторые администраторы тоже умудряются.
У IBM Storwize я не смог найти в своё время значения этого параметра, но во избежание проблем — так же стараюсь делить данные.
Если вы значение queue depth per LUN = 224 для VNX взяли из этого документа (https://www.emc.com/collateral/hardware/technical-documentation/h8229-vnx-vmware-tb.pdf) стр. 39, то вы читали не очень внимательно. Там речь про лун расположенный на пуле из 20 дисков, а не про максимум для LUN на массиве VNX.
Ну и для справки из документации вендора.
Расчет QD для Clariion CX4 и VNX1 с прошивкой v.31 идет по формуле QD=32+(14 умножить на количество дисков под данные)
Для VNX1 и VNX2 c прошивками v.32 и v.33 соответственно QD=(14 умножить на количество дисков под данные).
Отсюда для луна, расположенного на пуле из 20 дисков в Raid5 (4+1) (т.е. в пуле 4 приватные RG в указанной конфигурации) мы и получаем то самое значение 224=14 умножить на 16. Что как вы понимаете не является максимальным значением для LUN на массиве. Если возьмем пул из 60 дисков в той же конфигурации Raid5 (4+1), то соответственно получим QD для LUN=672.
Еще для справки, максимальный QD для одного порта FC на VNX = 1600. Что реально является ограничением. Правда слабо верится что вы сможете его достигнуть, учитывая, что для подключения хостов обычно используется несколько портов на СХД одноверменно.
Да не за что в общем то :). На многих хостах и HBA кстати QD ограничен 64-256 на том. Эти максимумы быстрее станут бутылочным горлышком, при наличии большом количестве VM, по сравнению с нормальной СХД.
Зачем бэкап? У нас же RAID