Рекомендации по настройке СХД Hitachi серии AMS 2000

Эта заметка будет посвящена ключевым рекомендациям по настройке и подключению СХД серии AMS 2000 от компании Hitachi Data Systems, в которую входят AMS2100, AMS 2300 и AMS2500. Многие из этих рекомендаций общие для всех СХД, многие уже известны, а некоторые относятся только к AMS.

Конфигурация СХД

На картинке ниже нарисована схема СХД, применительно к которой и будут описаны рекомендации.

image

А далее я опишу ключевые моменты обеспечения

 

Избыточность:

Избыточность в инфраструктуре хранения требуется для поддержания высокой доступности, масштабируемости и производительности. Причем масштабируемость требуется на каждом уровне сети хранения данных.

Для серверов ESX(i) – это избыточные HBA. Это позволит использовать встроенную поддержку multipathing, а так же предоставит защиту от аппаратных сбоев в HBA или проблем на Fibre Channel линках.

Избыточность Fabric тоже важна, так как сбой на единственном Fibre Channel коммутаторе вызовет ошибки на всех виртуальных машинах, подключенных к хранилищу через этот Fabric коммутатор.

Без избыточности в каждом компоненте, все виртуальные машины могут стать “жертвой” одной точки отказа.

В AMS 2000 series на СХД избыточность достигается двумя контроллерами доступа к LU с количеством FC портов от 2 до 8 на каждом контроллере. Для использования преимуществ такой конфигурации, каждый контроллер нужно подключать в двум или более FC коммутаторам. такой подход защитит от сбоев в FC линках, коммутаторах и контроллерах AMS.

Рекомендация: Подключайте не менее 2 Fibre Channel портов на каждом контроллере в разные FC коммутаторы, по 1 порту с каждой платы расширения Fibre Channel на контроллере

Если AMS 2000 подключены таким образом к ESX(i) хостам, то рекомендуется включить Round Robin алгоритм выбора пути на ESX(i) серверах, чтобы использовать все преимущества Symmetric Logical Unit Access контроллеров на СХД.

Зонирование

Это общая тема для всех СХД, я освещу только самые ключевые моменты.

Зонирование позволяет разделить FC фабрику на несколько логических частей для повышения безопасности и изоляции данных. Неправильное зонирование может вызвать ошибки презентования LU для хостов ESX, нестабильные пути и другие проблемы. Существует два типа зонирования и у каждого свои недостатки и преимущества:

По портам – использует указанные физические порты на FC коммутаторе. Зонирование по портам предоставляет большую защищенность и простоту при поиске неисправностей. Это может быть преимуществом в небольших статических инфраструктурах. Недостаток такого подхода в том, что HBA с ESX хоста всегда должны быть подключены к указанным портам, а переключение линка вызовет потерю соединения и потребует перезонирования.

По WWN – использует сервера имен на коммутаторах для привязки WWN HBA адаптера к WWN целевого порта. Преимущества такого подхода в том, что переключение физических линков от ESX HBA на коммутаторах не потребует перезонирования и, в динамических инфраструктурах, такой подход предоставляет большую гибкость. Недостатком подходя является меньшая защищенность и повышенная сложность при поиске неисправностей.

Зоны могут быть созданы любым из двух путей:

Multiple initiator (множественные инициаторы) – Несколько инициаторов (HBA) расположены в одной зоне с одной или несколькими целями. Такую конфигурацию легче создавать и она облегчает административную нагрузку, но может вызвать некоторую интерференцию потоков данных.

Single initiator (один инициатор) – Один инициатор (HBA) и одна или несколько целей расположены в одной зоне. Это исключает интерференцию, но требует создания зон для каждого инициатора (HBA).

При зонировании необходимо учесть все пути, доступные целям, чтобы multipathing был возможен.

Пример зонирования:

 

Хост Номер HBA на хосте Название зоны Порт на СХД
ESX 1 HBA 1 Port 1 ESX1_HBA1_1_AMS2K_0A_1A
OA
1A
ESX 1 HBA 2 Port 1 ESX1_HВA2_1_AMS2K_0E_1E
OE
1E

В этом примере каждый ESX хост имеет 2 однопортовых HBA. Каждый HBA зонирован к 1 порту на каждом контроллере, с 1 инициатором и двумя целями в зоне. В результате каждый HBA порт имеет два пути и 1 зону. Имея 2 HBA каждый хост получает 4 пути и 2 зоны.

Настройка HOST GROUP

Настройка Host Groups, а далее групп хостов, на Hitachi AMS 2000 позволяет указать какие HBA или группы HBA могут подключаться к LU через определённые порты на контроллерах.

Одна группа хостов на каждые сервер ESX, настройка изолированных хостов

Если хосты ESX работают в изолированном режиме, то есть вне кластера, то WWN каждого хоста может располагаться в собственной хост группе. Это рекомендованная настройка для инфраструктур с реализованной SAN Boot, так как сервера ESX не имеют доступа в загрузочным LU других серверов. Но такой подход может представлять собой административную головную боль, так как при большом количестве серверов LU c VMFS придется добавлять в каждую группу хостов, что может привести к ошибке из-за человеческого фактора.

Одна группа хостов на кластер, настройка хостов в кластере

Так как многие из возможностей vSphere требуют общее хранилище, такие как vMotion, DRS, HA, FT и Storage vMotion, то LU с виртуальным хранилищем должен быть презентован на все сервера ESX, участвующие в данных операциях.

Рекомендация: WWN всех серверов ESX нужно размещать в одной группе хостов на AMS

Опции групп хостов – Host Group Options

Группы хостов на семействе AMS 2000 создаются через Hitachi Storage Navigator Modular 2 (HSNM2). В модуле Available Ports, необходимо выбрать порты для которых применится конфигурация. Из списка Platform необходимо выбрать VMware, а из списка Common Setting, выбрать Standard Mode. В модуле Additional Settings нужно снять галки во всех позиций. Эти настройки автоматически применят правильную конфигурацию для серверов ESX.image

 

Hitachi Dynamic Provisioning Software

Что такое Dynamic Provisioning (DP) можно почитать в маркетинговых материалах. А в этой главе я укажу ключевые моменты использования Dynamic Provisioning для платформы VMware. Итак, начнем!

Эффективное использование дискового пространства с Dynamic Provisioning и типы виртуальных дисков

Я буду использовать формулировку thin-дружелюбность и её производные в этой части статьи. В оригинале эта формулировка выглядит “thin-friendly”. Thin-дружелюбность подразумевает под собой, что виртуальные диски отнимают чанки из пула Dynamic Provisioning только по мере необходимости. Два формата виртуальных диском vmware являются thin-дружелюбными: Thin и thick (он же zeroedthick). Диски формата Eagerzeroedthick занимают в DP пуле 100% своего пространства и не позволят сэкономить дисковое пространство, но они тем не менее могут быть полезны, так как позволят использовать wide-stripe и “размазать” виртуальную машину по всем дискам в DP пуле сразу.

Основные практики использования DP-томов для overprovisioning (ВМ занимает все выделенное ей место сразу):

Создавайте шаблоны ВМ в zeroedthick формате, если ваша vSphere не поддерживает VAAI. Для vSphere с поддержкой VAAI создавайте шаблоны в формате eagerzeroedthick. При создании ВМ из шаблона выбирайте: Использовать формат как у источника (Same format as source)

  • Используйте eagerzeroedthick для сред с VAAI
  • Используйте zeroedthick для сред без VAAI
  • Storage vMotion операция по перемещению ВМ с Dynamic Provisioning LU – это thin-дружелюбная операция.

Примечание: Перемещение ВМ с одного хранилища на другое не освобождает место на DP пуле.* Для этого нужно запустить процесс оптимизации пула на СХД вручную.

*Примечание 2: В vSphere5 новая VAAI команда UNMAP позволяет освобождать место в DP пуле при Storage vMotion. Но firmware СХД должна поддерживать эту команду.

Виртуальные диски и производительность Dynamic Provisioning

Для достижения максимальной производительности СХД в vSphere4 следуйте следующим рекомендациям:

Используйте eagerzeroedthick для избавления от задержки для обнуления блоков при первой записи. Для загрузочных томов ВМ можно использовать zeroedthick, так как там не требуется максимальная производительность.

Используйте не менее 4 RAID групп в Dynamic Provisioning пуле для достижения максимальной эффективности wide-страйпинга.

Если нет возможности создавать большие DP пулы, то стоит разделять случайные и последовательные нагрузки на разные DP пулы

Для приложений, использующих log recovery, нужно отделить логи от базы данных и расположить их на разных DP пулах. Это разделяет последовательные и рандомные нагрузки и позволяет повысить защищенность данных от возможных аппаратных сбоев.

Виртуальные диски на стандартных LU

Диски форматов zeroedthick и eagerzeroedthick имеют одинаковую производительность на стандартных LU после предварительной разметки. Но zeroedthick диски показывают чуть большую задержку во времени доступа и меньшую скорость так как разметка блока происходит в момент первого доступа к нему.При выборе zeroedthick или eagerzeroedthick дисков руководствуйтесь следующими пунктами:

Для использования vSphere Fault Tolerance нужно использовать eagerzeroedthick диски.

Если нужно сократить время создания виртуальных дисков, то используйте zeroedthick диски.

Если необходима максимальная изначальная производительность записи, то используйте eagerzeroedthick диски.

 

Распределение I/O нагрузки

Hitachi Dynamic Provisioning Software может балансировать I/O нагрузку между пулами  рейд-групп. Для vSphere 4 это можно считать зачатком Storage DRS, так как он не перемещает диски между пулами хранилищ, а только распределяет нагрузку по всем рейд-группам в пуле.

Вот так выглядит типичная картина DP-томов:

image

При использовании стандартных LU необходимо отслеживать производительность конкретных RAID-групп, что часто приводит к несбалансированной нагрузке на СХД.

image

Примечание: В vSphere 5 есть возможность использовать Storage DRS для балансировки нагрузки на СХД, но она доступна не во всех редакциях.

При использовании же Hitachi Dynamic Provisioning нет нужды отслеживать производительность индивидуальных RAID групп, так как этим занимается сама СХД и равномерно распределяет нагрузку по всем дискам в пуле. И тогда картинка будет выглядеть вот так:

image

Рекомендация: Максимальной эффективности от балансировки нагрузки виртуальных машин можно добиться при одновременном использовании Hitachi Dynamic Provisioning, round robin multipathing и VMware DRS.

vStorage API for Array Integration (VAAI)

В этой главе я опишу рекомендации по использованию VAAI с СХД AMS2000 и чего это позволит добиться. Про преимущества использования VAAI с AMS 2000 в vSphere 4.1 можете почитать в этом документе. А здесь я опишу что такое VAAI и рекомендации по его применению.

Аппаратное ускорение типовых операций vSphere с виртуальными хранилищами

В vSphere 4.1 было всего 3 команды VAAI:

Full Copy / Clone Blocks / XCOPY – функция, позволяющая передать на сторону массива возможности копирования объектов виртуальной инфраструктуры без задействования операций четния-записи со стороны сервера VMware ESX 4.1. Эту функцию также называют Hardware Offloaded Copy и SAN Data Copy Offloading.

Write Same / Zero Blocks – возможность обнуления больших массивов блоков на дисковых устройствах для быстрого создания дисков vmdk типа eager zero thick.

Atomic Test and Set (ATS) –возможность защиты метаданных тома VMFS как кластерной файловой системы в ситуациях, когда большое количество хостов ESX имеют разделяемый доступ к одному хранилищу. Также эта функция называется Hardware Assisted Locking.

Описание этих команд я взял из блога vmgu.ru, так как не вижу смысла переводить их самостоятельно. ЧТо они дают вы так же можете почитать в этой статье.

В vSphere 5 количество команд VAAI было расширено, но так как у меня нет vSphere 5, то я не могу провести какое-либо тестирование, а  Hitachi еще не опубликовало никаких подробных документов на эту тему. Так что я опишу здесь рекомендации для vSphere 4.1.

Итак, чтобы воспользоваться всеми преимуществами VAAI то придерживайтесь следующих рекомендаций:

  • Целевое и исходное виртуальные хранилища должны иметь одинаковый размер блока.
  • При клонировании RDM диска целевой диск тоже должен быть RDM.
  • При клонировании убедитесь, что диски не sparse и не hosted типов.
  • При клонировании ВМ у неё не должно быть снапшотов.
  • Исходный и целевой тома VMFS должны находиться на одной СХД
  • Аппаратное ускорение Thin Provisioning

    При использовании Hitachi Dynamic Provisioning с VAAI позволяет превратить eagerzeroedthick в thin диски на уровне СХД. В табличке ниже вы увидите результаты Provisioning операций для дисков разного типа.

    Тип виртуального диска Стандартные RAID группы Dynamic Provisioning том без VAAI Dynamic Provisioning том с VAAI
    Thin Thin Provisioned Thin Provisioned Thin Provisioned
    Zeroedthick Thick Provisioned Thin Provisioned Thin Provisioned
    Eagerzeroedthick Thick Provisioned Thick Provisioned Thin Provisioned

Как видите еagerzeroedthick диски на DP томах с VAAI и без получаются разного типа. А создание дисков любого типа на DP томе с VAAI создает thin диск на СХД. При этом еagerzeroedthick не требуется обнуление блока при первом доступе точно так же, как и на стандартных RAID группах и он сразу же предоставляет максимальную производительность записи.

Примечание: При конвертации Thin или Zeroedthick в формат Eagerzeroedthick в итоге получается Thick Provisioned диск. Для того чтобы снова сделать его thin на СХД нужно запустить zero page reclaim.

Включение VAAI на AMS2000

Чтобы использовать VAAI в вашей среде нужно, чтобы она удовлетворяла следующим условиям:

  • Версия ESX не ниже 4.1
  • СХД Hitachi AMS 2000 должна использовать firmware не ниже версии 0890/B
  • Hitachi Storage Navigator Modular должен быть не ниже версии 9.03

Так же в дополнение к стандартным настройкам HOST GROUPS необходимо дополнительно включить следующие параметры:

  1. Enable Unique Extended COPY Mode
  2. Enable Unique Write Same Mode
  3. image

Примечание: hardware assisted locking не требует дополнительного включения в настройках, он активен всегда, если ваша среда позволяет его применять.

Масштабируемость

Тут не существует единого правила, так что я лишь укажу общие моменты которые стоит учесть при планировании инфраструктуры:

  • Размер LU
  • Количество ВМ на 1 LU
  • Приемлемый уровень производительности
  • Размер виртуальных дисков
  • Количество виртуальных дисков на 1 ВМ
  • Тип нагрузки (последовательная, случайная запись/чтение)
  • Тип физических дисков
  • Размер физических дисков
  • Тип RAID групп
  • Конфигурация RAID групп

При проектировании вашей среды vSphere можете воспользоваться следующими рекомендациями:

  • Ориентируйтесь сначала на производительность, только потом на объем. Количество дисков для достижения необходимой производительности может быть больше, чем для ёмкости. При использовании Hitachi Dynamic Provisioning добавление RAID групп в пул позволит увеличить и емкость и производительность одновременно. Добавление в DP пул происходит без прерывания работы.
  • Учитывайте I/O требования приложений и старайтесь не превысить возможности RAID группы. Или используйте Hitachi Dynamic Provisioning для того чтобы минимизировать административную нагрузку.
  • Распределяйте разные типы I/O нагрузки между разными RAID группами, а так же распределяйте I/O нагрузки между RAID группами равномерно

    Выравнивание дисков и размер RAID Stripe

    Для достижения оптимальной производительности СХД необходимо правильно выровнять систему и диски, чтобы избежать дополнительных операций I/O. По-умолчанию AMS 2000 использует размер страйпа 256Кб, а VMFS3 использует размер блока 128К. Их необходимо выравнивать по границе в 128Кб.

    Убедитесь, что VMFS том правильно выровнен набрав команду:

fdisk -lu

image

Выделенное красным поле и значение 128 означает, что VMFS выровнен правильно. Если это не так, то почитайте эту инструкцию.

Так же необходимо правильно выравнивать диски виртуальных машин. Для выравнивания дисков в Windows смотрите этот гайд. Windows 2008 все новые диски по-умолчанию создаются правильно выровненными.

Настройки хостов ESX

Эта часть моей статьи будет самой короткой. Я не стану вдаваться в подробности и описание настроек, а лишь укажу те, который следует проверить или изменить:

  • Multipathing: используйте round robin.
  • Queue Depth: 32 для SAS дисков и 16 для SATA.
  • Disk.SchedNumReqOutstanding: используйте значение 32 даже для SATA дисков.
  • VMkernel Advanced Disk Parameters: используйте параметры по-умолчанию.

Заключение

На этом завершается моя статья. Прошу учесть, что большинство практик из этого документа применимы к vSphere 4.1. Я обновлю эту статью с учётом vSphere 5, как только она будет доступна конечным пользователям и у меня будет время провести тестирование всех пунктов заново.


Запись первоначально опубликована в блоге volnyanskiy.ru, автор Волнянский Виталий

 

14 thoughts on “Рекомендации по настройке СХД Hitachi серии AMS 2000”

  1. Виталий, а как связана рекомендация “включить Round Robin алгоритм выбора пути на ESX(i) серверах” с тем чтобы “использовать все преимущества Symmetric Logical Unit Access контроллеров на СХД”?
    Для каждого LU есть свой “активный” контроллер, второй – всего лишь “передаточный механизм”. От того что будем постоянно бегать по разным путям, никакие преимущества симметричного доступа не проявятся (на мой взгляд).

  2. Попробую ответить за Виталия.
    В текущей конфигурации у вас четыре пути до любого луна (два к одному контроллеру и два к другому).
    В силу асимметричного доступа, оптимальными следует считать те пути, которые ведут к контроллеру-владельцу луна. “Подсветкой” таких путей “занимается” ALUA, vSphere умеет с ней работать.
    Политика по умолчанию – MRU – использует один из двух оптимальных путей. Если вы выберете RR – задействуете оба. Учитывая, что на один “путь” можно выжать вполне конечное количество IOPS/MB, данная политика может помочь 😉

  3. Спасибо, Андрей, все так. Но ответ на вопрос Andrew Ivanov кроется во фразе “Symmetric Logical Unit Access”. AMS2000 не использует ALUA, так как оба контроллера владеют всеми LU сразу. В симметричных массивах не такого понятия, как “не оптимальный путь”, у них все пути являются оптимальными. То есть оба контроллера знают какой LU под какой нагрузкой, так же они знают загрузку другого контроллера. А имея между собой невероятно быструю шину обмена данными они балансируют нагрузку по обработке IOPS между собой.
    В той конфигурации, что я описывал в данной статье все 4 пути будут оптимальными – это ключевая особенность симметричных СХД. Тут нет нужны вручную балансировать LU между контроллерами, чтобы обеспечить равномерную загрузку, этим занимается ПО внутри СХД. И надо сказать делает оно это отменно, так как еще ни разу не было ситуации, что массив не справился с нагрузкой.
    Вкратце о том, какие есть типы массивов и принципы их работы можете почитать вот у этого товарища: http://vm.pro-it.kz/2011/02/storage-alua-multipath/#more-911
    Там не всё так подробно, как хотелось бы, но дает достаточное понимание о том, как работают разные типы стораджей.

  4. Мы с diz’ом дискутировали на эту тему…
    Решили, что все пути оптимальные, но есть пооптимальнее 🙂
    А именно, предполагается, что внутри СХД все же как-то делит диски между контроллерами. И доступ через контроллер-владельца все же будет пошустрее.
    Хотя, наверное, да – ключевой разницей между ALUA и SLUA-массивами является количество контроллеров и скорость обмена данными.
    Удивлен, что AMS2000 – симметричный сторадж – как-то невнимательно я читал твою статью, Виталий 🙂
    P.S. Хотя вообще да – я бы хотел узнать, как работают симметричные стораджи, вон как XP24000, например. Если чего найду – ждите откровений 😉

  5. @ A.Vakhitov
    Чтобы массив можно было считать симметричным он должен соответствовать “симметричности” по стандарту т10. Если почитать тех. документацию протокола SCSI2 и SCSI3, то та можно найти невероятное количество тонкостей и нюансов работы. Например то, что в симметриных массивах можно использовать ALUA, хотя реальной пользы от этого нет, просто тех. возможность. Тем не менее, важным фактором является то, что в симметричных массивах нагрузка от “не самых оптимизированных” путей на процессор и шину данных массива не влияет на производительность самой СХД

  6. deleburth

    Я обратил внимание, что вам очень нравится слово “невероятное”.
    Может быть вы расскажете и про минусы симметричных стораджей, ну просто для баланса к “невероятно быстрой шине”? 🙂

  7. @ romx
    Минусы:
    *Триадиционно для симметричных СХД: Очень дорого – в прошлом году AMS стоили страшных денег. На следующий год куплю Netapp:) В прошлом году покупка новой СХД NetApp, для построения распределённого кластера и виртуализации текущих стораджей, по стоимости была равна покупке двух “плотных” дисковых полок для AMS. Сейчас AMS стал дешевле раза в два, но всё равно цена не радует.
    *Реализация симметричности остается на совести вендора – нам не озвучивают как же она работает внутри СХД в конкретной реализации. В этом случае Active/Passive СХД от EMC/NetApp более понятны – там мигрирует весь могз в случае сбоя и процесс документирован.
    *Для AMS 2000, где два контроллера, администраторы СХД обычно смотрят общую нагрузку массива. И в момент когда она пеерпрыгнет суммарно 50%, а потом погибнет один из контроллеров (маловероятно) случится замедление работы. Можно расставить приоритеты LU, DP-Vol и разметить области в кэше вручную, чтобы критичные сервисы не пострадали. Но факт остается – такая конфигурация СХД расслабляет и при проблемах нужно будет часов 8-12 подпрыгивать и углубляться в оптимизацию работы СХД, пока прилетит новый контроллер. Или же переключить пути на резервный СХД, если он есть, временно отключив синхронную репликацию.

    Кстати, у Вас, romx, очень интересный блог. Читаю с удовольствием, а в связи с планируемой покупкой NetApp мне там вдвойне интересно 🙂

  8. @ deleburth
    Здесь кроется небольшая ошибка – AMS2000 имеет точно такую же привязку LU к контроллеру, как и большинство систем этого класса. Другое дело, что доступ к LU осуществляется через любой из двух контроллеров (по крайней мере, не наблюдается радикального падения производительности при доступе через “альтернативный” контроллер и не требуется смена контроллера-“владельца”). Но, тем не менее, для каждого LU есть свой контроллер и есть даже встроенный механизм балансировки LU между контроллерами для оптимизации производительности. Никакой балансировки между контроллерами по операциям ввода-вывода для одного LU нет. Хочется большего – добро пожаловать в мир USP-V/VSP! Вот именно к этому я собственно и придрался 🙂 Сам по себе round-robin плюсов не даст, тем более это никак не связано с “Symmetric Logical Unit Access”. Имея количество LU больше и равное числу путей до СХД, можно избавить себя от оптимизации загрузки линков. Но это единственной плюс. Видел когда-то тесты для EMC, где использование RR для одного LU давало снижение производительности (и это вполне объяснимо), хотя, повторюсь – для многочисленных LU RR может несколько упростить жизнь и поднять “интегральную” производительность.
    Кстати, в матрице совместимости, насколько я помню, для AMSок указано только VMW_PSP_FIXED.

  9. @ Andrew Ivanov
    Спасибо за разъяснение! Но я запрошу дополнительное разъяснение у тех. поддержки HDS 🙂

    Вот это написано в HCL VMware:
    Storage partners using ESX 4.0 or later may recommend VMW_PSP_RR for path failover policy for certain storage array models. If desired, contact the storage array manufacturer for recommendation and instruction to set VMW_PSP_RR appropriately.

    Официальная же рекомендация Hitachi – использование Round Robin, можете уточнить у тех. поддержки 😉 Так же эта рекомедация отражена в документах по AMS2000.

  10. Коллеги, а разве у ALUA-систем наблюдается деградация производительности при доступе к LUN с невладельца этого LUN? Насколько я разбирался, там трафик “топает” через интерконнект контроллеров и сильно бедой это не назовешь?

  11. @ Андрей Вахитов
    Не факт, что система вообще дает доступ через второй процессор (а не просто “показывают” луны хосту), без переброса на него LU. А если и дает доступ, то далее все зависит от “толщины” интерконнекта. Владельцы NetApp, например, знают на своей шкуре, что доступ через “альтернативный” путь это плохо.

    @ deleburth
    Спасибо. Я про FIXED вижу только в compatibility list – дальше не смотрел. При случае взгляну 🙂

  12. @ Andrew Ivanov
    Скажем спасибо коллегам из nvisiongroup за разьяснение.

    Я был действительно не совсем прав, вот ответ специалиста HDS:

    Привязка LU к контроллеру никуда не делась, и да – IO одного LU обрабатывает один контроллер.
    А вот если говорить подробнее, то тут начинаются отличия от большинства модульных массивов:
    1) Контроллер AMS2000 может и обрабатывает IO команды, поступившие на фронтэнд порты второго контроллера. Как и было замечено это происходит без вообще какой-либо потери в производительности.
    На этом основано собственно symmetric active-active io, обновление микрокода без падения линков итд.
    2) Балансировка LU между контроллерами (а в AMS2500 и между ядрами одного цпу на контроллере) происходит силами самого массива, но также это как и раньше может делать администратор. Смена LU ownership, автоматическая и ручная – онлайн процедура без какого-либо влияния на производительность.
    3) Благодаря такой архитектуре, для AMS2000 становится неактуальным понятие preferred path – администратор может не задумываться о выставлении предпочитаемых путей на хосте, независимо от OS/схемы подключения/MPIO софта на хосте

  13. Давно не занимаюсь Hitachi AMS, поэтому могу уже и напутать, но разве симметричный active-active не означает, что нам надо одновременно держать две копии данных в кэша на обоих контроллерах? Что означает, что объем кэша становится “виртуально” вдвое меньше, так как в общем объеме хранится по две синхронных копии каждого кэшируемого объекта – для одного и другого контроллера.

  14. Добрый день.

    Не хочу показаться лентяем попрошайкой, но не мог ли кто-нибудь подсказать где можно подробно почитать о AMS2000. Кроме Learning Centra HDS. И интересно узнать как происходить апгрейд СХД AMS2100 в 2300 и в 2500.

Leave a Reply

Your email address will not be published. Required fields are marked *