Я хочу заменить наше текущее хранилище. Существующая система - это всего лишь файловый ресурс 450 ГБ на нашем 7-летнем контроллере домена плюс еще 150 ГБ с другого сервера. Мы сопоставляем их с дисками на клиентских машинах. Оба обеспечивают резервное копирование на один ленточный накопитель емкостью 400 ГБ. Добавьте несколько состояний системы и базу данных sql server, и ночная резервная копия составит около 600 ГБ. Это больше, чем на одну ленту, и поэтому в настоящее время у нас есть резервное копирование в шахматном порядке, при котором мы берем только «полную» из 1/5 общего пространства каждую ночь в будние дни + разницу всего.
Чтобы заменить это, я хочу перейти на два выделенных сервера (основной, плюс зеркало и бэкап в одном). План для первого - это том RAID 1 для ОС + 2 тома RAID 10 2 ТБ для данных (4 диска + 1 горячий резерв каждый, всего 12 дисков по 1 ТБ, включая ОС). Другой план состоит в том, чтобы иметь те же 12 дисков емкостью 1 ТБ (зеркалирование с первого сервера каждую ночь). Он также будет иметь 2 тома RAID 6 по 6 ТБ (5 дисков по 2 ТБ каждый, отдельные тома для сокращения времени неизбежного восстановления), которые я планирую использовать существующее программное обеспечение резервного копирования для создания дифференциального моментального снимка каждую ночь. Это обеспечит хранилище истории / поколения для истинной резервной копии вместо нашей ленты, и должно быть достаточно места, чтобы получить примерно 30 дней (упрощенная проверка нашей скорости изменения показывает, что для этого мне нужно соотношение примерно 3: 1). 2-й сервер будет жить в дальнем конце кампуса, чтобы избежать необходимости брать что-либо с территории.
Я бы предпочел купить решение, поддерживаемое поставщиком, но здесь стоимость является огромной проблемой. Я знаю, что могу сделать то, что описал выше, за общую сумму около 13000 долларов (включая лицензирование ОС, спасибо академическим ценам для образовательных учреждений), поэтому путь ниже любого коммерческого варианта, который я видел. У меня есть надежный партнер по базовому шасси, картам RAID и объединительной плате, поэтому я знаю, что получаю там хорошее оборудование, и мне нужна качественная карта RAID. Я просто раньше не строил сервер такого масштаба, и отсюда у меня вопросы:
Есть ли что-то, что мне не хватает, из-за чего я без необходимости могу потерять данные? Что я должен делать или избегать при сборке, установке и настройке серверов? Пока ничего не было куплено, поэтому я открыт для других предложений, но цена является ключевой. Некоторые вещи, которые сразу бросаются в глаза, и которые я буду благодарен за комментарии:
Я бы очень опасался создавать свои собственные компьютеры. Хотя, похоже, вы довольно твердо настроены на это. Обязательно соблюдайте надлежащие антистатические процедуры при передаче оборудования. Старайтесь избегать использования жестких дисков из одной производственной партии исключительно при сборке томов RAID. Убедитесь, что диски, которые вы покупаете, были отправлены в надлежащей ударопрочной упаковке, как предписано производителем (а не в типично NewEgg "в их антистатических пакетах, брошенных в коробку с пузырьковой пленкой и арахисом").
Поскольку вы собираетесь построить свою собственную коробку, вам необходимо иметь в запасе достаточное количество запасных частей для трудно заменяемых компонентов на время предполагаемого срока службы системы. Наличие запасных частей - одна из составляющих «коммерческих» вариантов. Если вы потеряете объединительную плату, RAID-контроллер или материнскую плату, будьте готовы заменить их. Вы действуете как поставщик поддержки собственного оборудования. Это увеличит стоимость вашей покупки, но вам следует приобретать запчасти. сейчас пока они все еще доступны.
Я бы сильно встряхнул оборудование, прежде чем даже подумал об использовании его в производстве. Любое нагрузочное тестирование или симуляция использования в производственной среде, которую вы можете использовать для оборудования, - хорошая идея. Вы определенно хотите избавиться от любой "детской смертности" в оборудовании, прежде чем начинать производство.
«Зеркало» без нескольких предыдущих поколений - плохая внешняя копия. Если вы делаете «зеркало», чтобы позволить вам запустить резервный файловый сервер в производство в случае сбоя производства, то имеет смысл сохранить такое «зеркало». Однако, на мой взгляд, это не резервная копия. Это больше похоже на механизм резервирования, чем на механизм резервного копирования. Я настоятельно рекомендую использовать резервную копию, которая позволяет хранить несколько поколений изменений на удаленном сервере, даже если вы также поддерживаете функциональное «зеркало» данных на удаленном сервере для производственного аварийного переключения.
Рад слышать, что вы все еще собираетесь использовать ленту. Я большой поклонник хранения резервных копий вне сайта и офлайн. Автономные резервные копии хороши тем, что их целостность (при условии, что они созданы правильно) намного легче застраховать, чем систему, которая постоянно находится в сети. Удаленно атаковать данные на ленте в запертом ящике довольно сложно.
Лента также является отличным средством хранения архивов. Затраты на расширение окон хранения возрастают (в отличие от добавления дополнительных вращающихся носителей к решению, основанному исключительно на жестком диске). Я думаю, вам следует серьезно подумать об использовании ленты для хранения нескольких поколений всех ваших данных вне офиса и офлайн. Убедитесь, что вы выполняете все бизнес-требования по хранению долговременных архивов на ленте, и при необходимости планируйте приобретение дополнительных носителей. Вы можете хранить эти архивы в более географически удаленном месте, чтобы иметь возможность восстановления в случае серьезной физической аварии.
Если вы делаете резервную копию, которая действительно является «копией», вы не потеряете биты архива. Это зависит от программного обеспечения, которое вы используете.
Вот предложение относительно ваших резервных копий, которое может помочь уменьшить ваши потребности в хранилище:
Выполняйте полное резервное копирование SQL и состояния системы каждый день (если вам не удобно выполнять резервное копирование SQL на определенный момент времени).
Переключитесь на ежедневное инкрементное резервное копирование файлового сервера. Я работаю в сфере информационных технологий 11 лет и еще не сталкивался со сценарием («постучать по дереву»), когда мне потребовалась бы дифференциальная резервная копия для восстановления системы или данных. Мне может потребоваться вернуться через несколько дней инкрементальных операций, чтобы найти «версию» файла, который требуется восстановить пользователю, но это редко бывает, поскольку пользователь обычно хочет восстановить последнюю резервную копию. В случае полного сбоя системы в худшем случае вам потребуется восстановить несколько наборов инкрементных резервных копий, чтобы восстановить «синхронизацию» файлового сервера. Это, конечно, расширит ваше окно восстановления, и это может быть приемлемым или неприемлемым для вас и вашей организации.
Я подхожу к управлению системами с точки зрения «возможность против вероятности» и по моему опыту, хотя возможно, что мне может понадобиться дифференциальная резервная копия, это маловероятно ... из моего опыта. Это позволило мне уменьшить размер наших ежедневных резервных копий и окно резервного копирования.
Есть устройства с функциями репликации или, по крайней мере, удаленного дифференциального копирования, основанные на таких вещах, как открыть-е, Nexenta или Сервер хранения Windows там на рынке.
В целом, я бы предпочел не покупать компоненты для сборки их вместе в серверы, а покупать серверы / устройства с системной гарантией - они не будут стоить значительно дороже, но могут избавить вас от многих проблем в случае неисправности оборудования.
Кроме того, вы не должны использовать ленту «для резервного копирования SQL Server и состояния системы», а для копирования критически важных данных за пределы объекта. Тем не менее, вы должны следить за тем, чтобы сохранить историю - вероятно, включение SQL-сервера в стандартный процесс резервного копирования - хорошая идея.
Если вы являетесь магазином Microsoft и имеете право на лицензию для учебных заведений, вы можете изучить Data Protection Manager, чтобы заменить устаревшую версию BackupExec - это даст вам интересные функции и хорошую интеграцию с программным обеспечением Microsoft.
Чтобы уменьшить время резервного копирования / нагрузку на основной сервер, я хотел бы делать ночные резервные копии с зеркала. Но уничтожит ли копирование на зеркало бит архива, который мне нужен для получения хороших дифференциалов?
Да, это будет. Но дифференциалы в любом случае - плохая идея - они вам, вероятно, не нужны. Делайте полные резервные копии через разумные промежутки времени и храните их вне офиса. Ваша стратегия резервного копирования в первую очередь предназначена для смягчения последствий катастрофического сбоя - если оба ИТ-сайта вашего кампуса будут одновременно уничтожены в результате катастрофического события, вероятно, не имеет большого значения, потеряли ли ваши пользователи один или пять дней. данных - до тех пор, пока не будут потеряны все данные.
Я смотрю на 44 ТБ необработанного пространства на дисках, но предоставляю пользователям только 4 ТБ после выделения RAID и резервного пространства. Могу ли я безопасно добиться большего, чем это соотношение 11: 1?
Зависит от ваших требований к безопасности и производительности. Вы, вероятно, сможете сэкономить на настройке RAID 10 на своем «резервном» зеркале - если это не предназначено для непосредственного обслуживания пользователей, вы можете использовать менее производительную и менее дорогую настройку с чередованием с четностью (RAID 5, 6 или Z).
В Nexenta есть несколько отличных партнеров, таких как Pogo Linux, у которых есть решения, которые должны соответствовать вашему бюджету. Имейте в виду, что они могут помочь вам разработать решение в уменьшенном масштабе, которое будет обладать необходимыми возможностями расширения, чтобы вы могли расширять сеть SAN по мере необходимости. Если вы решите построить себя, есть вариант NexentaStor Community Edition, который, как я полагаю, в настоящее время ограничен 12 ТБ дисковой емкости, что, если вы используете дедупликацию и сжатие, где это необходимо, может означать, что вы фактически получите гораздо больше данных в этих 12 ТБ. выделенная мощность. Однако вы не сможете перейти на коммерческую версию Enterprise, если решите сделать это позже. Кроме того, если у вас есть несертифицированное решение, поддержка всегда является большей проблемой, чем партнерское решение. Существуют и другие варианты, но если у вас уже есть базовые знания Linux или еще лучше Solaris или Open Solaris, NexentaStor может оказаться отличным вариантом, поскольку базовая ОС является надежной и много общего с OpenSolaris.