Я начинаю видеть клиентов с сотнями терабайт данных (в установках SQL Server). Поскольку общий объем данных на некоторых предприятиях приближается к значимым долям петабайта, я хотел бы изучить имеющуюся там коллективную базу знаний, чтобы увидеть, что люди, имеющие дело с такими объемами данных, делают для их защиты.
Очевидная проблема заключается в том, что хранение нескольких резервных копий такого количества данных непомерно дорого, если использовать хранилище корпоративного класса, черт возьми, даже просто RAID-5.
Я вижу следующие варианты:
Я вижу вариант №4, принимаемый по умолчанию, и как специалист по HA / DR это действительно пугает, но что я могу посоветовать в качестве альтернативы? Я думаю, что №1 - лучший подход, но «Я так не думаю» - обычный ответ, когда предлагаются любые альтернативы, кроме №4 и, возможно, №3.
Теперь, конечно, это зависит от скорости изменения и важности данных. Нет необходимости отвечать на этот вопрос, поскольку я отвечал за все функции высокой доступности SQL Server, пока работал в Microsoft, поэтому я хорошо разбираюсь в аргументах «зависит от обстоятельств» - это моя популярная фраза :-)
Мне было бы очень интересно услышать о любых альтернативах, которые я пропустил, или о том, что все остальные находятся в той же лодке и нет реальной альтернативы тратить много денег на дополнительное хранилище.
Заранее благодарим - должное будет дано всем хорошо продуманным и высказанным ответам.
Да, еще один вариант - виртуализация хранилища: устройство, которое находится между вашими серверами и SAN, например IBM SVC. SVC управляет копиями SAN-to-SAN и может выполнять удаленную репликацию (хотя это, очевидно, довольно болезненно на петабайтном уровне, если только у вас не очень низкая скорость изменения данных и действительно высокая пропускная способность).
Самое интересное в том, что весь процесс невидим для задействованных серверов. Если вы используете SQL Server, вы проектируете свои файловые группы так, чтобы вещи с низкой скоростью изменения были вместе (например, архивы продаж более 3 лет назад), а вещи с высокой скоростью изменения (например, текущие продажи) в отдельной файловой группе. Они даже не обязательно должны быть полностью доступны только для чтения - вы просто хотите спроектировать их так, чтобы можно было использовать разные методы репликации для каждой файловой группы. Устройство SAN может синхронизировать LUN через сеть, ленту или через SAN, что означает, что вы можете отправлять части SAN туда и обратно. Это более эффективно с таким оборудованием, как LeftHand, где SAN состоит из пула участвующих единиц.
Затем вы можете автоматически синхронизировать данные с низкой скоростью изменения по сети и синхронизировать высокую скорость изменения с помощью sneakernet. (Похоже, у меня это задом наперед, но это правда - вы не можете синхронизировать материал с высокой скоростью изменения по проводу из-за громкости.) Даже некоторые из низкочастотных устройств теперь позволяют это: LeftHand позволяет реплицировать на другие Устройства LeftHand в вашем центре обработки данных, а затем отправьте их в удаленный центр обработки данных. Подключите их, присоедините к удаленной стороне, изменив IP-адреса и группы, и теперь они являются частью вашего удаленного резервного копирования SAN. Предложение LeftHand по этому поводу просто великолепно: настройте две сети SAN бок о бок в основном центре обработки данных, синхронизируйте их, а затем вы можете отправлять их части в удаленный центр обработки данных, в то время как некоторые из них остаются в вашем текущем. датацентр для синхронизации. Постепенно перемещайте их, не выходя из синхронизации.
Однако я не делал этого на уровне петабайтов. Вы знаете, что они говорят - в теории, в теории и на практике одно и то же. На практике...
Неординарная идея - вся хранимая информация нужна или даже полезна?
Сколько на самом деле стоит информация? Очевидно, нелепо тратить на содержание и управление больше, чем того стоят данные.
Подходят ли данные в базе данных для хранения в базе данных? Например, действительно ли хранение сжатых многогигабайтных файлов ядра в базе данных службы поддержки дает какие-либо реальные преимущества?
В базе данных много повторяющихся данных? Например, хранит ли тысяча человек по десять экземпляров еженедельного информационного бюллетеня объемом 10 МБ?
Есть ли у некоторых данных «срок годности», после которого они не представляют никакой ценности? Возвращаясь к примеру с организацией поддержки, по разным причинам практически бесполезно хранить основные файлы клиентов дольше, чем через несколько месяцев после доставки исправления.
Другая мысль - хранить столько данных, открывающих компанию к обязательствам. Некоторые данные необходимо хранить по закону. Однако некоторые данные следует «измельчить» из-за рисков, связанных с их случайной или злонамеренной передачей ненадлежащим сторонам.
Вариант 1 - это зеркалирование, что почти так же плохо, как и №4: любая ошибка, которая повреждает данные и не обнаруживается немедленно, повредит обе копии.
Если данные критичны, рассмотрите специальные решения; почитайте, например, о продуктах IBM Shark или конкурирующих продуктах от EMS и т. д. У них есть такие функции, как Flash-copy, которые позволяют мгновенно создать логическую копию файла без удвоения требований к диску; а затем вы можете сделать резервную копию этой копии (например) на ленту. Также обратите внимание на роботизированное резервное копирование на ленту.
Укажите тем, кто хочет хранить петабайт данных, что хранилище стоит недешево.
Мне так надоело, что люди жалуются на то, что у меня нет лишнего терабайта онлайн-хранилища, потому что диск дешевый - диск может быть, но управляемое хранилище, черт возьми, нет.
Если хранить резервные копии непомерно дорого, то безопасное хранение данных непомерно дорого, поэтому предлагаемое решение нежизнеспособно.
Одной из наиболее важных причин для создания резервных копий является защита от ошибок пользователя (большинство проблем с аппаратными сбоями можно решить с помощью аппаратных решений), но даже зеркальное отображение базы данных не является защитой от отброшенной таблицы (хорошо, вы можете защитить от этого, но все же возможно получить неустранимую болтовню в вашей БД - если только БД не настолько велика, потому что она выдает только вставки).
На мой взгляд, лента больше не является жизнеспособным решением - теперь дешевле просто работать с дисковыми массивами (хотя физическое хранилище может быть неудобным). Поэтому я думаю, что ваш единственный вариант - это какой-то метод разделения данных на фрагменты, достаточно маленькие, чтобы их можно было восстановить в разумные сроки, а затем регулярно помещать их на дисковое хранилище (и здесь могут помочь решения типа EMS, если у вас есть денежные средства).
Интересное видео с подробным описанием архитектуры myspace.com (серверная часть SQL2005). Не уверен, есть ли у них отдельные петабайтовые дБ, поскольку они масштабируются с несколькими дБ. Они используют резервное копирование SAN snap.
ZFS. Конечно, это только начало, но есть ряд областей, в которых ZFS предназначена именно для таких задач. Во-первых, это способность обрабатывать большие объемы данных, а также множество различных устройств хранения (локальных, SAN, оптоволоконных и т. Д.), При этом сохраняя безопасность данных с помощью контрольных сумм и осведомленности о состоянии устройства, "нарушающей уровень", и неудачи. Но как это помогает решить проблему резервного копирования такого большого количества данных?
Один из способов - использовать снимки. Сделайте снимок, отправьте его на ленту / диск / сеть для передачи на удаленный сайт. Последующие снимки отправляют только те данные, которые были отправлены, и при необходимости вы можете хранить данные в реальном времени на обоих концах.
Другой - использовать программное обеспечение Solaris Cluster, где (при наличии достаточной пропускной способности сети) вы можете иметь живое зеркалирование между двумя серверами, и если один из них выйдет из строя, второй может взять на себя управление. Это больше для использования там, где важна высокая доступность (HA), но я предполагаю, что большинство мест с таким большим объемом данных хотят HA.
И вы говорите, что ZFS не поддерживается в Windows, обычное место, где вы можете найти sqlserver, возможно, вы запускаете Sun / ZFS на бэкэнде и подключаетесь через iSCSI. Может быть, это тоже ужасная идея, но, по крайней мере, стоит подумать, чтобы вы знали, чего не следует делать.
Вы смотрели на Amazon Glacier как на вариант?
ИМО, если у вас нет какого-то оборудования уровня Godzilla, если у вас столько данных, вы должны использовать технологию сжатия резервных копий. Я больше всего знаком с LiteSpeed, но есть аналогичные продукты от других производителей и (конечно) аналогичная функция встроена в SQL2008. Вы можете не получить сжатие 10: 1, но оно снижает требования к хранилищу для резервной копии, а также может уменьшить требования к окну резервного копирования. Если ваша цель состоит в том, чтобы сохранить несколько наборов резервных копий (вчера плюс день до этого, плюс один с прошлой недели и один с прошлого месяца, или серия дифференциалов плюс полные, которые могут стать очень большими, если вы измените много данных в базу данных), это просто вопрос места для хранения.
Резервное копирование на основе файловых групп (IOW, размещение энергонезависимых данных в определенных FG и резервное копирование нечасто) никогда не срабатывает, потому что разработчики или пользователи не могут или не могут решить, какие данные являются нестабильными, а какие нет, и в заброшенном поле сценарии, которыми вы часто не можете рискнуть.
Если отказоустойчивый сайт является обязательным, вы можете не только подумать о зеркале базы данных, но и поговорить с поставщиком хранилища ваших клиентов, чтобы узнать, предлагают ли они что-то вроде SRDF, который представляет собой аппаратную технологию репликации данных. Естественно, репликация (любого рода, но особенно репликация в реальном времени или почти в реальном времени) не заменяет резервное копирование.
Я не думаю, что у вас есть большой выбор здесь, на ленте против диска. Лента, скорее всего, не обрежет ее в обычном окне резервного копирования, если вы ее не разделите, и я не уверен, что в этом надежность.
Итак, вы приступили к резервному копированию на диск. Вы версионируете? Это означает, что вы беспокоитесь о том, чтобы вернуться к резервной копии 2 (текущая база данных минус 2 резервные копии)? Или бэкап 3? В этом случае у вас могут возникнуть проблемы, но, вероятно, вам придется обрабатывать резервные копии журналов, а не резервные копии данных.
Если вы можете разделить некоторые данные как доступные только для чтения / неизменяемые, то, возможно, у вас есть управляемые размеры резервных копий / окна. Или, по крайней мере, вы надеетесь, что технология резервного копирования и пропускная способность догоняют рост данных.
Я не думаю, что вы создаете столько же резервных копий, сколько храните вторую копию, чтобы исправить проблемы с вашим основным. Это означает, что оборудование, повреждение и т. Д., И вы ежедневно молитесь, чтобы ошибки не отправлялись во вторую копию. Скорее всего, копии делаются по сети SAN-SAN с использованием технологии моментального снимка. хотя исходная копия может быть отправлена через Fed-Ex, а не по сети. Пропускная способность для передачи 100 ТБ достать никому не просто.
Я думаю, вам нужна комбинация 1, 2 и 3 (не 4) с отличным управлением резервным копированием журналов.
На самом деле я думаю, что в любой момент времени вы действительно просматриваете 3 копии своих данных. Запуск CHECKDB на одной из копий, в то время как вторая копия используется для фактического получения изменений. Затем вы снимаете эту вторую копию с первой и продолжаете. С таким большим количеством данных я полагаю, что здесь вам потребуется некоторое усердие. Пол, как checkdb работает на многопользовательской базе данных объемом 100 ТБ, подключенной к сети?
Как уже упоминалось, не критичны ли резервные копии журналов и, возможно, программа чтения журналов? Разве вам не нужно восстанавливать отбрасываемые таблицы / ошибки пользователя из журналов, а не из резервной копии? Вы можете сократить это, отправив копии SAN с некоторой задержкой, но я не видел этой технологии. SAN с доставкой журналов, которая может задерживать изменения на 4 часа (или на некоторый интервал), чтобы вы могли устранить проблемы до перезаписи данных. Или какой-нибудь инструмент для чтения журнала изменений блока SAN? Без этого вам нужно управлять этими журналами транзакций, что может быть совершенно другим уровнем отслеживания этих резервных копий в различных файловых системах в течение нескольких xxx часов, чтобы вы могли потенциально восстанавливаться после нефатальных ошибок.
Технически хранение является дешево, но на уровне петабайтов не так уж и много. Это действительно зависит от приложения, но я бы сказал, что ответом будет некоторая комбинация стратегий №2 и №3, причем №2 - заданное, а №3 - в зависимости от того, сколько инвестиций вы можете вложить в хранение и вид хранилище и ввод-вывод / вычислительная мощность, которые позволят вам обойтись без инкрементаризма и с максимально незаметным полным резервным копированием.
В качестве альтернативы, что-то вроде Amazon S3 также может вступить в игру в зависимости от вашей пропускной способности и количества изменений в данных - при таком объеме размещение хотя бы части из них на чужих серверах и предоставление им возможности беспокоиться о избыточности становится все больше и больше. экономически эффективным.
Поговорите со своим поставщиком хранилища, у него будет продукт дедупликации, который они использовали раньше, в сочетании с регулярным сжатием вы часто можете уменьшить объем данных на 70%. Конечно, любой, у кого есть деньги, которые можно потратить на петабайт хранилища, также, вероятно, будет иметь бюджет, чтобы купить достойное решение для резервного копирования - если у них нет, тогда вам просто нужно спросить их, во что потеря этого петабайта будет стоить их бизнесу.
В большом корпоративном хранилище данных большая часть данных поступает из источников, для которых уже созданы резервные копии. Я работал над установками Teradata и ODW, где они выбрали вариант №4, но знали, что они могут восстановить данные транзакций за день или два и преобразовать их из исходных систем.
У одного розничного клиента (в то время у них был один из 5 крупнейших DW в мире, объемом около 200 ТБ ... дает представление о том, как давно это было), они выбрали вариант № 1 после покупки нового петабайта. -класса сервера Teradata. Старые узлы будут использоваться для моментального снимка системы предыдущего дня, в то время как новые узлы сохранят существующие. Это было также хорошо с точки зрения аварийного переключения - время от времени они отключали все для обслуживания, и мы просто переключались на использование старого медленного сервера с данными дневной давности.
Честно говоря, это казалось большой тратой обработки / хранения и т. Д., Чтобы продолжать работу ... особенно когда самым большим преимуществом было то, что их администраторам и специалистам NCR приходилось работать меньше вечеров для выполнения нерегулярного обслуживания.