Многолучевость против связанных соединений

Question

Многолучевость против связанных соединений

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

2

database hp sql storage-area-network cat5e

Источник

Derek Colley 29 сен '11 в 08:16

1 ответ

Другие вопросы по тегам database hp sql storage-area-network cat5e

Paweł Brodacki 29 сен '11 в 09:32 2011-09-29 09:32 · Answer 1 · 2011-09-29 09:32

Я не уверен, что вы подразумеваете под связью в контексте SAN.

Многолучевое распространение в SAN выполняется в первую очередь для RAS. У вас обычно есть пути к независимому LUN. Это означает, что разные карты FC, разные матрицы, разные контроллеры памяти. Если ваше хранилище поддерживает активную / активную работу, вы также можете использовать пропускную способность обеих ссылок (вы можете отправлять запросы параллельно по обеим из них).

Если ваше хранилище не поддерживает активную / пассивную работу, то использование многолучевого распространения означает, что вы потеряете половину полосы пропускания, поскольку вы сможете общаться с LUN по одной ссылке в любой момент времени.

Однако потеря пропускной способности (если таковая имеется), на мой взгляд, более чем приемлема, учитывая возросшую доступность. Таким образом вы устраняете SPOF на стороне хранилища и, например, можете шататься при обновлении прошивки SAN / изменениях зонирования, не рискуя повлиять на производство (если после обновления коммутатор FC выходит из строя, вы можете просто переключиться на другую матрицу, пока люди SAN выполняют стратегию восстановления).