Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Расширение SAN с помощью WAN

Эрик Сигел, Билл Террил

Предприятиям снова нужны централизованные хранилища данных. Однако для подключения удаленных пользователей к такому хранилищу и для передачи в него подлежащих резервированию данных вам потребуется пересылать трафик между сетями SAN по каналам WAN.

Представьте кошмарную для любого ИТ-специалиста ситуацию: проверяя штаб-квартиру вашего предприятия, бригада ревизоров требует предъявить ей тысячи файлов. ИТ-специалисты стараются как можно быстрее найти их архивные копии, в том числе и те, которые хранят в удаленных филиалах, и восстановить затребованные файлы, но, поскольку на это уходит немало времени, ревизоры все больше раздражаются. Если какие-то файлы найти не удастся, например, из-за потери или случайной порчи архивного носителя, ревизоры могут обвинить руководство компании в преднамеренном уничтожении деловой информации.

Этот кошмар, порожденный новыми законодательными актами США, которые регламентируют хранение корпоративной информации, и выгоды от централизации ИТ-операций заставляют предприятия пересматривать свои подходы к управлению ИТ-системами и хранящимися на них данными. В итоге серверы приложений и системы хранения данных оказываются сосредоточенными в корпоративном центре обработки данных (ЦОДе), удаленном на сотни километров от конечных пользователей сети. Этот ЦОД может оказаться единственной точкой отказа для всей корпоративной ИТ-инфраструктуры, если хранящиеся в нем данные не будут реплицироваться. При такой реорганизации ИТ-инфраструктуры сетевым приложениям филиалов корпорации, ранее работавшим с локальной сетью SAN, придется взаимодействовать с сетью SAN корпоративного ЦОДа, возможно, через всю страну.

Но не печальтесь по этому поводу: почти все производители оборудования сетей SAN предлагают решения для передачи их трафика по WAN-каналам (SAN-over-WAN — SoW), благодаря которым приложения осуществляют доступ к удаленным базам данных так, как если бы последние были локальными. “Не подозревая” о том, что подключены к сети SAN по каналу WAN, приложения и ОС используют стандартные программные интерфейсы SCSI и Fibre Channel, команды которых перехватываются драйвером или устройством SoW, а затем по WAN-сети передаются в интерфейс удаленной системы хранения данных.

Сейчас для передачи трафика сетей SAN по крупномасштабным IP-сетям широко используются три протокола:

• iSCSI (Internet SCSI) — инкапсулирует стандартные команды интерфейса SCSI-3 в поток данных TCP/IP.

• FCIP (Fibre Channel over TCP/IP) — инкапсулирует стандартные пакеты Fibre Channel в поток данных TCP/IP. Существуют альтернативные решения, передающие трафик Fibre Channel по ATM-сетям и сетям других типов;

• iFCP (Internet Fibre Channel Protocol) — перехватывает пакеты Fibre Channel и заменяет их TCP-сеансами.

К сожалению, технологии SCSI и Fibre Channel предназначены для коротких каналов, соединяющих вычислительные системы с устройствами хранения данных, которые обычно находятся в одной и той же комнате или даже в одном и том же монтажном шкафу. Поскольку эти технологии разработаны в расчете на почти нулевой уровень ошибок в канале и такую же задержку передачи пакетов, в работе SoW-протоколов FCIP, iFCP и iSCSI по сетям WAN возникают определенные проблемы.

Снижение пропускной способности WAN-каналов

Каналы WAN-сетей характеризуются высоким уровнем возникающих в них ошибок (до 0,5%) и значительной временной задержкой передачи пакетов (например, в волоконно-оптической линии она составляет 5 мкс на километр). В прямом канале связи между Нью-Йорком и Лос-Анджелесом задержка равна 20 мс, а в спутниковой линии, проходящей через геостационарный спутник, — примерно 260 мс.

Трудности с пересылкой данных по WAN-каналам возникают из-за того, что протокол TCP и SoW-протоколы заставляют передающее устройство приостанавливать свою работу после передачи разрешенной квоты пакетов данных (называемой окном) до получения подтверждения их успешного приема. Отправка подтверждений необходима для гарантии безошибочности связи и управления потоком данных, но она снижает реальную пропускную способность WAN-канала. Рассмотрим передачу файла по 45-Мбит/с спутниковому каналу связи (см. рисунок). Как уже говорилось выше, задержка передачи пакетов по каналу на базе геостационарного спутника составляет около 0,26 с, а принимающее ПО TCP по умолчанию поддерживает окно размером 17 520 байт.

В нашем примере пересылка 17 520 байт данных (от передатчика к приемнику) длится 0,26 с, столько же времени уходит на пересылку подтверждений в обратную сторону, что необходимо для возобновления передачи данных. Таким образом, примерно за полсекунды удается передать только 17 520 байт, а реальная пропускная способность 45-Мбит/с канала оказывается равна всего-то около 35 Кбайт/с.

Эта проблема характерна для любого длинного высокоскоростного канала связи. Например, задержка передачи данных по прямой наземной линии между Нью-Йорком и Мельбурном (Австралия) составляет 0,1 с.

Ситуация становится еще хуже, если в ходе передачи пакет теряется или искажается. “Полагая”, что потеря пакета всегда вызвана перегрузкой сети, протокол TCP существенно (по меньшей мере вдвое) снижает скорость передачи данных, а потом медленно наращивает ее до первоначального уровня. Темп наращивания зависит о круговой задержки передачи пакета по каналу связи: чем она больше, тем больше времени длится этот процесс. Потеря значительного числа переданных пакетов может парализовать передачу данных на какое-то время. При этом сами данные не потеряются, но пропускная способность канала сильно снижается, и приложению, осуществляющему, например, удаленное резервирование данных, придется долго простаивать в ожидании подтверждений.

Оптимизация решений SoW

Она имеет огромное значение для их успешного функционирования. Существуют три основных способа оптимизации: сжатие трафика WAN, настройка протокола WAN и, если осуществляется репликация базы данных, выбор подходящего метода репликации.

Сжатие трафика WAN

По многим каналам передается повторяющийся трафик в виде неоднократно пересылаемых одних и тех же строк (последовательно-стей символов). Сжимая последние, средства сжатия уменьшают число пакетов, передаваемых по WAN-каналу, уменьшая тем самым время простоя системы в ожидании подтверждений.

Многие системы SoW, снабженные элементарными функциями сжатия, стараются не передавать излишний объем информации, но они часто не могут обнаружить повторяющиеся последовательности в блоках данных с разными адресами. Реализуемые в таких системах методы сжатия обычно не столь эффективные, как в специализированных устройствах.

Лучшие в этом отношении продукты имеют большие словари сжатия, которые позволяют заменять мегабайты данных одним маркером и тем самым значительно экономнее расходовать полосу пропускания канала связи. Установив оптимизирующие производительность каналов устройства на обоих концах WAN-соединения, вы получите высокую степень сжатия, не внося какие-либо изменения в систему SoW. Представители таких компаний, как Expand Networks, утверждают, что трафик систем SoW хорошо подходит для обработки улучшенными алгоритмами сжатия. По словам специалистов Expand Networks, применение ее WAN-акселераторов, как правило, сокращает потребность в полосе пропускания на 90%.

Настройка протокола WAN

Его нужно настраивать в самих устройствах SoW и их сетях. Увеличив размер TCP-окна (на сколько это позволяют объемы буферов) и задействовав функцию выборочного подтверждения (selective acknowledgment) на обоих концах канала, вы уменьшите задержки, возникающие при управлении потоком данных и потере пакетов.

Во многих сетях имеется возможность увеличения размера пакетов, что снижает нагрузку на ЦПУ хост-машины и уменьшает число передаваемых подтверждений. Однако чрезмерное увеличение размера пакетов TCP приведет к их фрагментированию промежуточными устройствами для передачи по каналам с ограниченным размером пакетов. При этом бывает, что фрагменты пакетов теряются и нагрузка на узлы сети повышается из-за сборки фрагментированных пакетов. Повысить производительность сети SAN можно с помощью дополнительных плат расширения, на которых размещены средства шифрования трафика и обработки TCP-пакетов.

Если оптимизация работы устройств SoW и сети WAN не дает значительного повышения ее пропускной способности, задействуйте специализированные устройства, предназначенные для оптимизации функционирования сетей WAN. Уменьшая число циклов передачи и решая проблемы, связанные с размером TCP-окна и возникновением ошибок, эти устройства позволят вашему SoW-решению использовать всю полосу пропускания WAN-канала.

Expand Networks, Orbital Data, Peribit Networks и другие компании продают устройства оптимизации работы сети, которые обеспечивают высокую интенсивность передаваемых потоков данных даже при большом числе ошибок, возникающих в высокоскоростном канале со значительной задержкой передачи пакетов. Работая парами (по одному устройству на каждом конце канала), эти устройства, как правило, весьма эффективно сжимают поток данных. Для взаимодействия с системами SoW они используют обычный протокол TCP, а для связи друг с другом (по сети WAN) — хорошо оптимизированные специальные протоколы.

Компании Brocade Communi-cations Systems, Cisco Systems и McData предлагают коммутаторы и маршрутизаторы, оптимизирующие работу сети SAN и протокола TCP, но их функции сжатия и TCP-оптимизации менее эффективны, чем аналогичные функции вышеупомянутых устройств оптимизации работы сети.

Синхронная или асинхронная?

С репликацией баз данных связаны дополнительные трудности в организации работы системы SoW. Для преодоления их огромное значение имеет правильный выбор метода репликации данных — синхронного или асинхронного.

При синхронной репликации в сети SAN записываемые данные передаются локальному и удаленному запоминающим устройствам одновременно, а ПО репликации подтверждает их запись приложению, инициировавшему эту операцию, только после сохранения этих данных на обоих устройствах.

Большая задержка в передаче пакетов крайне негативно влияет на производительность приложений при использовании синхронной репликации данных. Даже без потери пакетов и обусловленной ею повторной передачи последних связанные с управлением потоком данных проблемы, которые вызваны задержкой их пересылки, снижают пропускную способность WAN-каналов. Если не компенсировать задержку, то при синхронной репликации данных сети SAN по каналу длиной более 100 км возникнет задержка в получении подтверждений, способная вызвать существенное снижение производительности приложения. Благодаря использованию средств сжатия данных и настройке WAN-протокола можно задействовать каналы длиною в сотни километров и при этом не бояться возникновения проблем, связанных с задержками.

Асинхронная репликация данных, широко используемая в сетях SAN, существенно сокращает время простоя приложения. При такой репликации сеть SAN передает подтверждение приложению при успешном сохранении данных локальным устройством, не дожидаясь, когда это же сделает удаленное устройство. Таким образом устраняется негативное влияние задержки, но, поскольку данные на первичном и вторичном (локальном и удаленном) устройствах не всегда синхронизированы, нет никакой гарантии, что удаленное устройство предоставит свежие данные для восстановления сетевых сервисов после аварии в работе ИТ-системы.

И наконец, некоторые производители оборудования для сетей SAN реализовали в своих продуктах возможность частой пересылки моментальных снимков данных на удаленное запоминающее устройство, что обеспечивает наличие контрольных точек синхронизации, начиная с которых приложение может возобновлять свою работу при выходе из строя локального устройства памяти. Для восстановления работы приложение подключается к удаленному устройству и использует хранящуюся на нем базу данных. Результатов ряда транзакций в ней не будет, но приложение “знает”, когда делался последний моментальный снимок и что нужно перезаписать все транзакции, которые осуществлялись после этого..


продажа микронаушников на microushki.ru .Микронаушники всегда помогут сдать экзамены, ЕГЭ и сессию




  
13 '2005
СОДЕРЖАНИЕ

бизнес

• Microsoft закрепляется на новых рыночных нишах

инфраструктура

• Тестируем ПО репликации данных

• Расширение SAN с помощью WAN

• Кондиционеры для сетей мобильной связи

• Устройства Wi-Fi становятся частью обстановки SOHO

• Тестируем решения IP KVM

информационные системы

• Как победить на рынке BPM

сети связи

• Переходим на MPLS

• VoIP операторского класса

кабельные системы

• Новый виток развития ПО управления СКС

• Оптическая кабельная инфраструктура для центров обработки данных

защита данных

• IP-камеры завоевывают рынок

новые продукты

• Платформа инспекции и управления трафиком операторского класса; Отечественные маршрутизаторы; Обновленная NEAX 2000 IPS; Модули CWDM для коммутаторов OptiSwitch 9000; Коммуникационная платформа Siemens Hipath 1100


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх