Мне нужен совет по настройке доступа ввода-вывода для нескольких хостов в нашей SAN:
У меня есть блейд-корпус (PowerEdge1000e), содержащий блейд-хранилище Equallogic PS-M4110 с одним томом RAID6, в настоящее время отформатированным как ext4.
Он подключен через iSCSI к одному из других блейд-серверов (все работают под управлением сервера ubuntu 14.04) и смонтирован там как стандартный диск.
Теперь я пытаюсь подключить другой блейд-сервер в корпусе к SAN таким образом, чтобы разрешить ввод-вывод с несколькими хостами.
Желательно избегать очевидного решения NFS, потому что некоторые из немного сомнительно закодированных инструментов, которые мы используем, имеют привычку давать сбои и сгорать при выполнении больших операций ввода-вывода в NFS. Это особенно проблематично, поскольку для запуска этих инструментов требуются недели, и у них не так много возможностей для проверки (вы уже догадались, что это академическая среда?).
Однако все работает нормально с текущей настройкой iSCSI. Поэтому я склонялся к кластерной или распределенной файловой системе + iSCSI как к лучшему варианту, но меня беспокоят проблемы с разделением мозга и т. Д., Поскольку у нас есть только 1 узел.
1) Является ли что-либо из вышеперечисленного хоть сколько-нибудь разумным?
2) Есть ли у вас какие-либо рекомендации, какие fs использовать (предпочтительно совместимость с FOSS и linux)?
iSCSI, как уже упоминалось, является протоколом блочного доступа - он просто проходит через Ethernet. Это ужасный план - пытаться выполнять ввод-вывод с несколькими хостами на одном блочном устройстве. Большинство кластеров по какой-то причине не поддерживают это. Вам нужно беспокоиться о кэшировании на разных уровнях ОС и об атомарности ваших операций ввода-вывода.
Даже с одним "доступным для записи" и одним "только для чтения" хостом, по сути, всегда читается "грязная" файловая система. Я написал решения для резервного копирования, которые - эффективно - делают это путем создания копий клонов, проверки целостности клонов и их монтирования для резервного копирования. Это все еще ТОЛЬКО работает, потому что я явно очищаю буферы данных / хоста и гарантирую, что я отдельно записываю журналы транзакций, чтобы я мог «воспроизвести» и исправить грязную файловую систему.
NFS существует не просто так, и она действительно обеспечивает доступ к файловым системам Unix с нескольких хостов довольно чисто. Это не идеально - вы можете споткнуться из-за блокировки файловой системы, но, по крайней мере, вы не повреждаете свою файловую систему каждый раз, когда ее используете.
Для начала выясните, почему ваши инструменты теряют популярность в NFS - вы можете обнаружить, что это связано с мягким или жестким монтированием или тайм-аутом в NFS. Или попробуйте переключиться с TCP на UDP или наоборот.
Если вам действительно необходимо использовать iSCSI, я бы посоветовал вам - как я обрисовал выше - использовать подход клонирования экземпляра, а не совместно используемый параллельный ввод-вывод.
iSCSI - это протокол блочного уровня, который читает / записывает на необработанный диск по сети. В нем нет концепции блокировки файлов. Поскольку это также сетевой протокол, он позволяет несколько подключений к одной цели. Вы должны быть в состоянии гарантировать, что файловая система уровня выше iSCSI будет иметь адекватную блокировку файлов для предотвращения одновременной записи.
Никогда не пробовала (уж слишком страшно). Я слышал примеры, когда люди разрешали одной машине доступ для чтения / записи, а другим - только для чтения. Очевидно, многое зависит от того, чего вы хотите от этих томов. Например, содержимое на диске сервера SQL, очевидно, потребует глубоких знаний о механизме блокировки, используемом этим сервером, и, возможно, возможности таблицы только для чтения.