OES2018SP1 + SoftRaid1 + NSS

[BDmV]

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

сейчас смотрю в сторону mdadm (raid1) + LVM + NSS
или есть более надёжные методы...

зы. главное, чтобы ещё при постановлении ОС не пришлось танцевать с бубном для поднятия томов.

[Иван Левшин aka Ivan L.]

Поддержка OES2018SP1 прекращена 31.05.21, почему Вы ее не обновляете до SP3?
NSS умеет создавать программный RAID еще со времен Netware, зачем md, LVM и прочее вообще?
Практика расширения пула NSS путем добавления в него носителей является порочной: повреждение любого из носителей отправляет в страну вечной охоты весь пул. Оно Вам действительно надо?

[BDmV]

Поддержка OES2018SP1 прекращена 31.05.21, почему Вы ее не обновляете до SP3?
NSS умеет создавать программный RAID еще со времен Netware, зачем md, LVM и прочее вообще?
Практика расширения пула NSS путем добавления в него носителей является порочной: повреждение любого из носителей отправляет в страну вечной охоты весь пул. Оно Вам действительно надо?

1. На ручное обновление у меня, пока нет времени.
2. Вот насколько надёжен этот программный raid от netware? ни разу его не использовал.
3. md (ну или raid от nw) сохранит доступ к файлам при накрытии 1го диска и пул не отправится в страну вечной охоты. (Теоретически) (связка md + lvm именно так и описывается)

зы. Я понимаю, что 6 томов на 6-и 600G винтах это минус "вечная охота", но хочется из существующих дисков собрать, что-то не менее надёжное и более объёмное.

[Иван Левшин aka Ivan L.]

Чем, любопытно, отличается программный RAID от Novell от того, чем является md?
Оно работает. Точно не хуже, чем md. Я работал и с тем, и с другим, никакой существенной разницы не заметил и не ощутил. Правда, идея создать NSS на md мне в голову не приходила никогда вообще...
Я не берусь прогнозировать, что произойдет, если вывалится 1 диск из зеркалированного пула. Если честно, я просто никогда ничего подобного не проверял - по той простой причине, что абсолютно уверен в порочности такой практики. Идеи "а давайте соединим 4 винта по 500 Гб и получим пул размером в 2 ТБ! Ну красота же!" мне приходится обсуждать совсем не в первый раз. Ответ - очень прост: оцените, пожалуйста, риски самостоятельно. При этом обязательно не забудьте посчитать, сколько у вас резервная копия размером 2 Тб разматываться будет. По моим сведениям размотать 2 Тб - развлечение на сутки-двое.
Пока еще никто не смог меня убедить в реальной необходимости существования томов даже 1 Тб, про 2 и далее я уже молчу. Большие тома - это ужасно неудобно в случае Disaster Recovery, Вы и теряете сразу все (а не отдельные кусочки), и восстанавливаете это потом очень долго (выслушивая благодарное начальство, которому в такие моменты, почему-то, строго параллельна красота идеи загнать все на один огромный том, а вот то, что бизнес-процессы стоят потому, что доступа к данным нет - наоборот, волнует прям до нервного срыва временами).
Намного более правильной стратегией является поддержание нескольких относительно небольших томов, а не одного-двух огромных. Оно только в мечтах выглядит красиво, в реальной жизни это адский геморрой (простите мой французский).
В программировании есть принцип KISS (Keep It Simple, Stupid) - как по мне, так он не только в программировании применим.

[BDmV]

Чем, любопытно, отличается программный RAID от Novell от того, чем является md?
Оно работает. Точно не хуже, чем md. Я работал и с тем, и с другим, никакой существенной разницы не заметил и не ощутил. Правда, идея создать NSS на md мне в голову не приходила никогда вообще...
...

Для Вас, скорее всего нечем.
Для меня, как минимум кол-вом информации в инете.

зы. если не секрет. Как вы боритесь с нехваткой дискового пространства? чисто заменой дисков?

[Доменика]

Чем, любопытно, отличается программный RAID от Novell от того, чем является md?
......
Ответ - очень прост: оцените, пожалуйста, риски самостоятельно. При этом обязательно не забудьте посчитать, сколько у вас резервная копия размером 2 Тб разматываться будет. По моим сведениям размотать 2 Тб - развлечение на сутки-двое.
Пока еще никто не смог меня убедить в реальной необходимости существования томов даже 1 Тб, про 2 и далее я уже молчу. Большие тома - это ужасно неудобно в случае Disaster Recovery, Вы и теряете сразу все (а не отдельные кусочки), и восстанавливаете это потом очень долго .....
.......
Оно только в мечтах выглядит красиво, в реальной жизни это адский геморрой (простите мой французский).
В программировании есть принцип KISS (Keep It Simple, Stupid) - как по мне, так он не только в программировании применим.

2Тб в наше время - ни что. Если это виртуальная среда, то дисковой полкой 12 на 2Тб, уже ни кого не удивишь. И это нижний предел. Развалиться дисковая полка или то что лежит на ней - это уже не принципиально. И как в таком случае существовать?
По дискуссии можно предположить, что необходимо иметь много ... много серверов на отдел\группу с размером тома до 1Тб.
Или можно иметь сервер и на нём много ... много томов по отделам\группам.

Идеология развертывания серверов 20 лет назад и сейчас изменяется?
Или как-то меняются методы восстановления\работоспособности в OES.
Количество информации растёт и всё больше это не бумага.

[Иван Левшин aka Ivan L.]

Доменика, при всем моем к Вам уважении - и лично к Вам, и к Вашему опыту работы, я все же не могу удержаться от вопроса: Вы вообще когда-нибудь сталкивались с необходимостью восстановить хотя бы 2 Тб данных? Разговоры о том, что есть "что", а что - "ничто", непродуктивны в любое время. Я, безусловно, в курсе, что накопители большой и сверхбольшой емкости применяются давно и повсеместно. Равно как и отвечаю на вопросы "а как мне сделать пул размером в 2 Тб".
Например, в моей практике были случаи, когда у одного и того же заказчика отваливались (из-за волшебной системы виртуализации Citrix Xen 6) тома размером "всего" (по Вашей логике это, конечно, "всего") в 2 Тб. Общее число таких томов было 2-3 за один раз. Лежали на них данные GW. Резервные копии, конечно же, были - сейчас я не хочу и не буду обсуждать тот момент, что, например, в случае с активно используемым ГВ дельта даже в день - это может быть очень больно и для пользователей, и для бизнеса. Скажу лишь о том, что просто разматывание с ленты томов в 2 Тб заняло от 6 часов до суток. Если Вы и в этот раз мне хотите сказать про "ничто", так я Вам замечу, что это означает, что ГВ был недоступен для пользователей, чьи данные находились на поврежденных томах, в течение как минимум рабочего дня. Все это время IT-руководство имело вполне себе бледный вид, т.к. руководству бизнеса вообще наплевать на "все эти ваши болтики и гаечки", им надо, чтобы бизнес-процессы крутились...
Экстраполируйте, пожалуйста, на 12 Тб самостоятельно. Подумайте, что Вы скажете руководству, когда до него дойдет, что бизнес стоит просто из-за того, что у Вас, понимаешь ли, резервная копия еще не размоталась.

Я был и остаюсь категорическим противником хранения оперативных данных (под ними я понимаю данные, которые нужны всем либо подавляющему большинству пользователей каждый день и много раз в день) на томах размером больше 1 Тб. Сейчас существует множество технологий организаций хранения данных: это и Multi Tiering, и широчайшее применение средств виртуализации (когда можно нарезать "виртуальные жесткие диски" чуть ли не по гигабайту размером), и прочие ухищрения. Тома размером в 2 Тб и далее могут применяться только для архивов: там нужно много/очень много места и данные, что там лежат, не нужны каждый день. Потому, если оно, внезапно, гикнется - никто не умрет от того, что резервная копия будет разматываться неделю. А то, что активно используется в работе... Нет, нет и еще раз - нет.

А в идеологии файлового сервиса и резервного копирования уже лет 20 (если не больше) ничего кардинально не меняется. Никаких "особых требований " в OES также нет. Обсуждаемая проблема находится целиком в области нормальной организации архитектуры информационной системы. Надеюсь, Вы понимаете, о чем я - если нет, скажите, пожалуйста, мне не сложно объяснить дополнительно.

[Доменика]

Доменика, при всем моем к Вам уважении - и лично к Вам, и к Вашему опыту работы, я все же не могу удержаться от вопроса: Вы вообще когда-нибудь сталкивались с необходимостью восстановить хотя бы 2 Тб данных? Разговоры о том, что есть "что", а что - "ничто", непродуктивны в любое время. Я, безусловно, в курсе, что накопители большой и сверхбольшой емкости применяются давно и повсеместно. Равно как и отвечаю на вопросы "а как мне сделать пул размером в 2 Тб".
......

Давно, но было.
NetWare 6.5.x + GroupWise 8.x. том 1.2Тб (HP Proliant 380G4 (диски 6 х 300Гб)
Почтовое отделение отправило в ночи сервер в абэнд.
Рестарт, том не грузиться.
Далее ~ 12 часов ожидания восстановления. Заработало.
Да, неприятные ощущения в ожидании.

Сейчас пользователи требуют увеличения почтовых ящиков.
Надо разбрасывать сотрудников по нескольким ПО + по нескольким серверам.
Я понимаю опыт, проблемы.
Но должны быть решения, практики.
Как было 10-15 лет уже не применимо.

[Иван Левшин aka Ivan L.]

Мы всегда пытаемся "натянуть" неограниченные хотелки пользователей на весьма (порой - очень весьма) ограниченные возможности. Конкретно в том случае, о котором я писал, я рекомендовал заказчику пересмотреть стратегию распределения пользователей по почтовым отделениям. Они очень быстро и с огромным удовольствием согласились и в настоящий момент их ПО ограничены, если мне не изменяет память, 200 или 400 Гб.
Касаемо "должны быть решения": они таки есть Например, есть Filr, с которым можно интегрировать GW следующим образом: вложения (прикрепления) размещаются в файлере, в письмах ездят только ссылки. Это очень сильно сокращает объем ПО, т.к., фактически, все громоздкие вложения лежат отдельно от писем - и, к слову, меняется и стратегия резервного копирования, т.к. ГВ и файловые сервера (на которых лежат вложения, собственно - мы настоятельно не рекомендуем использовать внутреннее хранилище файлера при наличии файловых серверов) резервируются отдельно и, часто, параллельно. Таким образом, мы и риски, с одной стороны, снижаем, с другой - сильно сокращаем время восстановления временами.
А вообще основная проблема - в том, что пользователи просто по-идиотски часто используют ГВ. Опять же из практики: мы две недели разбирались в причинах дикого торможения ГВ, пока админы совершенно случайно не обнаружили, что две тетеньки, сидящие через стенку, обмениваются многогигабайтными фотоархивами на тему "как мое дитятко провело лето". Эмоции команды по факту обнаружения я, боюсь, вряд ли смогу описать.

Коллеги, если кому интересен Filr - дайте знать, давайте соберемся и я покажу, что это такое и с чем его едят. Ну и на вопросы отвечу.