Недавно я попытался продать идею использования нескольких путей для одной из наших производственных баз данных (спасибо Brent на саммите SQL Pass!), В настоящее время использую только 1 файл базы данных (189 ГБ !!!) на физическом сервере с 2 линиями к HP LeftHand P4000 SAN ( через переключатели и т. д.). Одним из аргументов против этого было то, что две линии, выходящие из SAN, в настоящее время связаны, обеспечивая 2 x 1 Гбит / с r / w возможность к и от SAN. Администратор SAN не был готов к разделению линий, отчасти из-за того, что их использовали другие виртуальные машины на сервере, а также из-за неизвестного влияния, которое могло иметь любое разделение. Я изо всех сил пытался сформулировать преимущества многопутевого доступа к базе данных перед лицом этого - есть ли какие-либо преимущества, которые принесет m / p по сравнению с связанными соединениями?
Я не уверен, что вы имеете в виду, говоря о связях в контексте SAN.
Многопутевость в SAN делается в первую очередь для RAS. Обычно у вас есть независимые пути к LUN. Это означает разные карты FC, разные фабрики, разные контроллеры хранения. Если ваше хранилище поддерживает активную / активную работу, вы также можете использовать пропускную способность обоих каналов (вы можете отправлять запросы параллельно по обоим из них).
Если ваше хранилище не поддерживает активную / пассивную работу, то использование нескольких путей означает, что вы потеряете половину полосы пропускания, так как вы сможете разговаривать с LUN по одному каналу в любой момент времени.
Однако потеря пропускной способности (если таковая имеется), на мой взгляд, более чем приемлема, учитывая повышенную доступность. Таким образом вы устраняете SPOF на стороне хранилища и, например, может поэтапно обновлять прошивку / зонирование SAN, не рискуя повлиять на производство (если после обновления коммутатор FC выйдет из строя, вы можете просто переключиться на другую фабрику, пока специалисты SAN выполняют стратегию восстановления).