Возможно, это глупый вопрос, но мне было интересно, можно ли использовать несколько путей для массива хранения через соединение FC и соединение iSCSI? Учитывая, что основной целью использования нескольких путей, по-видимому, является повышение устойчивости перед лицом отказа оборудования, кажется логичным, что предоставление пути хранения, зависящего от сетевого оборудования, было бы подходящей устойчивой альтернативой пути, основанному на FC.
Я понимаю, что производительность может быть неодинаковой для обоих, но может ли это быть приемлемым недорогим решением, когда не хватает бюджета для нескольких соединений FC (и фабрики)?
теоретически, если device-mapper-multipath обнаружит один и тот же LUN по каналу iSCSI, он добавит его к доступным путям, а затем вам нужно убедиться, что вы установили направления аварийного переключения и ввода-вывода с правильными приоритетами. Однако я сомневаюсь, что вы увидите такое же представление LUN, потому что я не видел никаких массивов, которые позволяли бы экспортировать LUN и цели на основе одного и того же пула блочных устройств. Если вам известно о таком устройстве, поправьте меня, так как я, очевидно, не видел всех возможных SAN.
Я полагаю, что вы могли бы. Вероятно, это будет зависеть от поставщика вашего хранилища. Лично я бы купил и потратил бюджет на другой коммутатор оптоволоконного канала и дополнительные адаптеры главной шины.
Если ваша SAN поддерживает это (Compellent поддерживает, я не знаю о других), вы, безусловно, можете. Однако будьте осторожны с выбранной политикой выбора пути, то есть с тем, как MPIO выполняет балансировку нагрузки. Настройте FC в качестве предпочтительного пути и используйте iSCSI для аварийного переключения или наоборот (в зависимости от того, какая структура предпочтительнее, исходя из скорости, перегрузки, надежности и т. Д.). Избегайте балансировки нагрузки (например, циклического перебора) с использованием путей из обоих протоколов.