Что надлежащий путь состоит в том, чтобы завершить работу цели iSCSI со связанными клиентами?
iSCSI с двумя основными узлами DRBD является плохой идеей использовать, если два пути получают параллельные запросы записи. Но я думаю об использовании этой идеи как устройство хранения данных бэкенда для ESXI 5.5U2 хост.
Я уже протестировал это с основными/вторичными конфигурациями и классическим отказоустойчивым кластером.
То, что ESXI делает в этой точке, - то, что это обнаруживает многопутевое использование und только один путь активно. Таким образом в этой совокупности параллельная io-проблема записи, кажется, не возникает.
Теперь проблема в обоих случаях (основной/вторичный или основной/основной): Как я завершаю работу сервера iSCSI (iSCSI предназначаются для поставщика в терминах iSCSI), который имеет активные открытые соединения с клиентом iSCSI (инициатор iSCSI в терминах iSCSI)?
Я в настоящее время использую CentOS 5 на целевых серверах.
CO5 использует tgtd для обеспечения целей. К моему удивлению нормальные сбои метода остановки, если существуют соединенные клиенты. Вместо этого forcedstop, кажется, то, в чем я нуждаюсь в этом случае.
Я хочу завершить работу одного сервера чисто (я должен остановить доступ к цели, таким образом, я могу переключить drbd на вторичное устройство), и другой сервер должен затем автоматически стать активным (ничто, чтобы сделать там в этой совокупности, по моему скромному мнению).
Вопросы в том контексте: следующее хорошо, или я пропускаю что-то?
- принудительная остановка tgtd (будет сначала офлайн цели),
- разъедините IP в направление инициатора (другая строка, чем используемый для drbd-репликации)
- завершите работу drbd (делающий это вторичный первый)
- перезагрузка или сервер завершения работы
Да, я кое-что пропустил. Проблема все еще в том, что базовый протокол (SCSI) является протоколом с отслеживанием состояния . Таким образом, даже если мне удастся выключить цель (например, с помощью принудительной остановки), инициаторы активности останутся в "зависшем" состоянии.
Но: В моем варианте использования есть решение проблемы.
- в vCenter отключит все пути к определенному iSCSI-серверу.
- Это упорядочит все открытые iSCSI-транзакции и откроет новые транзакции на другом пути к другому серверу.
- После этого iSCSI-Server можно безопасно перезагрузить без прерывания работы клиента.
- После того, как iSCSI-сервер снова будет запущен и снова заработает, исходные пути iSCSI могут быть повторно активированы путем включения этих путей в vCenter.
Таким образом, правильный ответ на мои вопросы, кажется, будет следующим:
Коротко : Нет правильного пути. Ваши клиенты будут зависать.
Длинный: Это зависит от обстоятельств. Если у вас есть промежуточный уровень, который может сначала должным образом заглушить / завершить iSCSI-трафик, вы можете завершить работу целевого объекта впоследствии (даже если целевой сервер по-прежнему считает, что есть подключенные клиенты-инициаторы).