Назад | Перейти на главную страницу

Как я могу настроить временную отработку отказа для общего ресурса smb, предназначенного только для записи?

Мне поручено настроить сервер хранения, который будет использоваться для «приема» данных от машины Illumina, выполняющей очень дорогие операции секвенирования ДНК с ограниченной возможностью прерывания. Сам секвенсор подключается к ПК с Windows, предоставленному поставщиком, для запуска управляющего программного обеспечения, которое ожидает путь, по которому он может выгружать данные (около 12–16 ТБ в течение нескольких недель). Сервер хранения предоставляет для этой цели общий ресурс с использованием CentOS / samba. Мой вопрос: есть ли способ заставить общий ресурс, установленный на ПК с Windows, «переназначить» или, по крайней мере, кэшировать в локальное хранилище в случае отказа сервера хранилища или сети? И, конечно же, я хотел бы получить уведомление о том, что это произошло. Имейте в виду, что мы не можем просто отразить все локально, потому что не хватает места. В основном я хочу, чтобы программное обеспечение секвенсора могло продолжать запись в общий ресурс, пока есть некоторое локальное пространство для хранения данных, пока они не будут синхронизированы. Если это возможно, я бы, конечно, добавил один или два дополнительных диска, чтобы увеличить время, необходимое для устранения проблемы.

Я в основном специалист по Unix, поэтому я приветствую указатели на "очевидные" решения в мире Windows. Я не хочу устанавливать всевозможные сумасшедшие сторонние вещи на машину Windows секвенсора, но надежные, проверенные решения, вероятно, подходят.

РЕДАКТИРОВАТЬ: следует добавить, я не против, если есть творческое решение, которое вообще не использует smb.

TL; DR: важно то, что а) клиентское программное обеспечение Windows видит путь, по которому оно может записывать файлы данных б) так или иначе эти файлы попадают на сервер хранения в) в случае сбоя сетевого подключения или сервера хранения будет некоторое окно времени, в котором программное обеспечение не будет заблокировано и может продолжить запись данных, используя локально подключенное хранилище в качестве кеша.

На самом деле, нет. Вы можете настроить отказоустойчивый кластер для общего ресурса NAS, что снизит вероятность сбоя. Однако это не исключает возможности потери данных, а просто снижает количество точек отказа.

Правильный способ сделать это, если потеря данных недопустима, заключается в одном из двух:

  1. Примите меры к поставщику программного обеспечения, чтобы не допустить потери данных при исчезновении сетевого хранилища.
  2. Попросите программное обеспечение записать локально, а затем вы напишите сценарий копирования, который не будет копировать, если сетевое хранилище исчезнет.

Какой выход у секвенатора ДНК ?? Я предполагаю, что это супер большая база данных, разделенная на файлы размером 2 ГБ? Вы можете написать небольшой пакетный файл, который проверяет наличие более двух файлов и копирует тот, который имеет самую старую измененную дату, а после его успешного завершения удаляет его. (при условии, что он выводит только файлы и не нуждается в старых файлах), если по какой-либо причине копия не работает (например, NAS выходит из строя), он просто не удаляет локальные файлы и отправляет электронное письмо.

IMHO стабильный NAS имеет столько же шансов выйти из строя, как компьютер, подключенный к секвенсору ДНК, да, сеть может выйти из строя, но если у NAS есть запасной порт Ethernet, вы можете просто подключить их напрямую, используя кроссовер (или нет, MDIX и такой ...)

Странная проблема. Это то, что вы ожидаете от централизованной среды хранения, потому что вся ценная работа выполняется централизованно серверами, однако я никогда не слышал, чтобы кто-то делал это с одинарным хранилищем.

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

Это простая проблема, которую можно решить, если у вас есть все деньги в мире - просто установите кластерное запоминающее устройство, которое поддерживает географическое смещение узлов и имеет запущенный драйвер с несколькими путями. Netapp, использующий метрокластер, является примером этого, и если вы смотрите на диски, SVC от IBM с разделенной парой ввода-вывода и, возможно, даже с зеркалированием VDisk.

edit: @mfinni заставил меня задуматься о скриптах. Вы говорите, что вашему управляющему приложению нужен «путь» к большому сетевому ресурсу - нужно ли ему знать, что он большой? Что, если бы вы дали ему указание на запись на локальный диск? Можно ли настроить его для записи файлов определенного, достаточно маленького размера, чтобы можно было запустить сценарий, который будет передавать их на NAS, когда они закрываются управляющим приложением?

Кроме того, он будет записывать на ленту? Ленточный накопитель идеально подходит для таких приложений, работающих только с записью - каждый картридж вмещает 1,6 ТБ несжатых данных.