VIOS NextGen
VIOS NextGen aka Shared Storage Pools
Начну как всегда с отмазки от ответственности - сам я никогда Shared Storage Pools не юзал и в ближайшее время не собираюсь. Вам также не советую - ибо сыро оно еще. Все ниже описанное является личным мнением автора и не претендует на всеобщую вселенскую истину. Мало того, все нижеописанное может как являться правдой, так и никогда ей не стать в силу того, что программисты IBM опять обо...тся (вставьте корень слова по собственному желанию). И самое важное - если кто-либо посчитает, что эта писанина нарушает NDA, сообщите мне, я ее потру.
Я хотел бы немного приоткрыть тайну над тем, с какого перепоя IBM изобрела кластер из одной ноды для VIOS. Впервые я познакомился с VIOS NextGen (позднее переименнованным в VSCSI NextGen, а затем маркетоидами в Shared Storage Pools) в прошлом году, где-то в июле-августе. Знакомство, как вы понимаете, было заочным - я их вживую не видел, только набрел на необъятных просторах интранета IBM на описание того, что планируется сделать в светлом будущем из VIOS. Честно - после прочтения первой части началось обильное слюноотделение. Вторая часть его мгновенно прекратила - я прочитал про ограничения Фазы 1. Вторично я вернулся к этому вопросу где-то в октябре-ноябре, когда уже была пора выходить новому VIOS‘у и мне было жутко любопытно, что ж такого там выйдет. К моему величайшему огорчению разработчики VIOS‘а все также планировали включить VIOS NextGen в ближайшую версию, но при этом багтрекер ломился от ошибок, которые по моему скромному мнению были несовместимы с жизнью пациента. Результат известен - VIOS NextGen вышел только в качестве SP1 к VIOS 2.2 и с возможностью создания кластера только из одной ноды. Честно говоря, полнейшее разочарование от технологии, которая должна была стать очередным модным веянием в виртуализации. Но я все-таки порассуждаю на тему, а что было бы, если бы...
Итак, наши системы по известному плану IBM, должны быть уже давно полностью виртуализированы, а это значит, что весь ввод-вывод в них идет через мой любимый VIOS. На настоящий момент для виртуализации дисковой подсистемы у нас есть два варианта: VSCSI и NPIV. NPIV считается более современным и более универсальным - LUN‘ы подключаются напрямую к LPAR‘ам, администратор LPAR‘а «не знает», что они виртуализированы, и может использовать стандартные драйвера от производителя стореджа для MPIO или еще каких-либо дополнительных функций. Дополнительной работы для администратора VIOS практически никакой - только создать маппинг между физическим FC HBA и LPAR‘ом. Зонинг прописывается точно также как и для LPAR‘ов, подключенных через физический FC HBA. И к тому же - практически никакого оверхеда на виртуализацию. Ситуация близкая к идеальной.
VSCSI, наоборот, технология «полной» виртуализации, когда клиент видит не тот LUN, который выделяет администратор стореджа, а некий виртуализированный суррогат, доступный по урезанному подвиду протокола SCSI и с использованием специального драйвера VSCSI (к счастью, он входит в поставку AIX). Соответственно зонинг настраивается между системой хранения и VIOS‘ом, а администратор стореджа ничего не знает про конечного потребителя. И совершенно точно так же в отличие от NPIV здесь требуется больше работы от администратора VIOS и больше места для ошибок. После того, как LUN выделен VIOS‘у, необходимо найти его (а попробуйте найти LUN, если у Вас в VIOS‘е их штук 500 и Вам нарезали еще 20 новых), и правильно смаппить на нужный vhost. Ну и к этому еще прибавляется оверхед на трансляцию из FC в VSCSI. И пусть IBM утверждает, что это практически не заметно, но мы-то знаем...
При всем при этом не является великим секретом, что реализация NPIV в VIOS‘е мягко говоря не самая идеальная - достаточно посмотреть на количество ошибок, которые фиксятся в каждом сервиспаке. Кроме этого многие клиенты отказываются внедрять NPIV из-за проблем с безопасностью данных. Если вы меня спросите - каких, я вам не отвечу. С моей точки зрения VSCSI менее безопасный чем NPIV, но специалистам виднее.
Пораскинув мозгами, светлые головы в IBM придумали замечательную вещь, которая в очередной раз должна спасти мир от всех проблем, а заодно обеспечить рабочими местами десяток безработных админов - VIOS NextGen. Итак в нашем зоопарке есть уже N-ное количество серверов IBM Power, на каждом из которых установлено как минимум 2 VIOS‘а (мы ж Ынтырпрайз, а не в песочнице играем?). Если у нас, предположим, 10 серверов, то это уже 20 VIOS‘ов и куча стореджа, который к ним подключен. Если к каждому из серверов подключено по 100 ГБ стореджа и 90% из него используется, то у нас распределенного между LPAR‘ами, но не используемого места - 180 ГБ. Не очень эффективное использование ресурсов, не правда ли? Я не буду вспоминать, что 90% использования стореджа - очень хороший показатель, и обычно клиенты заказывают себе сторедж с запасом на несколько лет вперед и никогда его не используют. А в этот замечательный момент времени на одном сервере, как всегда жутко важном для бизнеса организации, не хватает места. И как на зло на сторедже тоже место все закончилось - нужно закупать новые диски, либо еще хуже - новый сторедж, а электричества в датацентре на установку очередного бегемота нет и ближайший месяц не будет, пока не будет подписано очередное допсоглашение о выделении еще сотни-другой киловатт на наш любимый датацентр. И тут еще пришли коллеги из отдела тестирования и просят срочно соорудить им тестовую среду точно с такими же данными, как на продуктивной, и нужно еще пару десятков ГБ стореджа, а потом останавливать продуктивную БД и копировать ее на тестовую систему, что потребует очередного RFC, десятки согласований и работу в выходные, которую HR забудет оплатить. Знакомая ситуация? И не надо говорить, что вот у вас все заведено по уму и такого не случается.
Для решения подобных проблем и подходит VIOS NextGen. В идеале все, что требуется сделать, это объединить все VIOS‘ы, которые у вас есть, в один (или несколько) кластеров. После этого сторедж выделяется (настраивается зонинг) на все VIOS‘ы в кластере. Таким образом, на любой машине Вы видите абсолютно все LUN‘ы для всех клиентов. Это, конечно, плохо и небезопасно, но это мы оставим пока за скобками. Из этих LUN‘ов создается пул дисков, из которого в свою очередь выделяются диски клиентам. Им они доступны все по тому же старому протоколу VSCSI. Но на стороне VIOS‘а эти диски становятся thin-provisioned, т.е. клиенту не выделяется сразу же весь запрошенным им объем, а только тот объем, который реально используется. Остальное место остается свободным. Мы получаем некоторую дополнительную свободу в распределении дискового пространства между клиентами и между машинами. Одни и те же диски, входящие в один кластерный пул, могут быть розданы клиентами на десятке различных машин. И за счет thin provisioning‘а мы получаем возможность использовать временно неиспользуемое место для других LPAR‘ов, дожидаясь пока приедет наша очередная DS8000/Hitachi USP/EMC Symmetrix/что-там-еще-мы-хотим-купить. И поскольку весь сторедж кластеризован между всеми машинами, нам нет нужды заботиться о том, на какой из машин требуется сторедж - он там есть. Больше того, нам нет нужды заниматься ре-зонингом, или перенарезанием LUN‘ов - все уже отзонировано заранее и нарезано, осталось лишь выделить сторедж LPAR‘у. Отсюда также вылезает еще одна приятная особенность - Live Partition Mobility становится еще более lively. Поскольку сторедж уже смаппирован на все VIOS‘ы, нет нужды тратить время на проверку, а есть ли там сторедж (он там есть), на перетаскивание WWPN‘ов, на ремаппинг vfchost‘ов, а также страдать, выявляя непонятные ошибки (а Вы видели такую веселую ошибку, когда LPAR уже смигрировал, а на системе-источнике он остается существовать в статусе Migration - Active? И ничего Вы с ним больше не сделаете - только выключать целиком всю машину).
Вторая замечательная особенность - это клонирование стореджа. Нужна Вам новая тестовая среда? Нет проблем! Продуктивная работает на Power 770, а на свободном завалявшемся Power 740 клонируете сторедж для продуктивной среды в новой LPAR (главное, чтобы VIOS‘ы были в том же кластере). При этом, как и полагается, клон занимает места примерно 0,0 ГБ. А зачем жрать нужное и дорогое место, если данные еще не изменены? Вот когда они изменятся, мы используем немного места под лог этих изменений. А пока - переживут тестеры, ничего с ними не случится!
А как Вы делаете бэкап со своей «самой важной» базы данных? Все так же останавливаете всю систему на 5-10 часов? А ведь это простой и деньги Вашей организации. Не будем мелочиться - создадим еще один LPAR, сделаем снэпшот с продуктивной системы и отдадим его R/O новому LPAR‘у, а потом можно будет на новом LPAR‘е делать бэкап ближайшие 23 часа - до нового окна. А "старый" продуктивный будет продолжать работать и обслуживать клиентов.
И то, что когда-то давным давно у меня не получалось со старыми версиями VIOS‘а (а с новыми я не пробовал) - быстрое развертывание AIX. Делаем LPAR, устанавливаем туда эталонный AIX, а затем на уровне VIOS‘а говорим, что вот этот диск, отданный AIX‘у, - это наш имидж, из которого в дальнейшем должны создаваться копии новых дисков под rootvg для всех новых LPAR‘ов. И все. Новый LPAR, почти готовый к работе (нужно только поменять IP-адреса), за 5 минут. Ну или сколько времени у Вас занимает создать новый LPAR в HMC и замаппить на него диски с VIOS‘а.
Вот такая сказка про VIOS, которая могла бы стать былью в конце прошлого-в начале этого года. Надеюсь, что еще станет к концу этого года. Хотя бы частично. Вопросы производительности я оставлю за скобками, потому что пока нет готовой реализации очень сложно рассуждать, насколько весь этот функционал будет тормозить систему. Но то, что он не будет ее ускорять, с моей точки зрения очевидно.
Начну как всегда с отмазки от ответственности - сам я никогда Shared Storage Pools не юзал и в ближайшее время не собираюсь. Вам также не советую - ибо сыро оно еще. Все ниже описанное является личным мнением автора и не претендует на всеобщую вселенскую истину. Мало того, все нижеописанное может как являться правдой, так и никогда ей не стать в силу того, что программисты IBM опять обо...тся (вставьте корень слова по собственному желанию). И самое важное - если кто-либо посчитает, что эта писанина нарушает NDA, сообщите мне, я ее потру.
Я хотел бы немного приоткрыть тайну над тем, с какого перепоя IBM изобрела кластер из одной ноды для VIOS. Впервые я познакомился с VIOS NextGen (позднее переименнованным в VSCSI NextGen, а затем маркетоидами в Shared Storage Pools) в прошлом году, где-то в июле-августе. Знакомство, как вы понимаете, было заочным - я их вживую не видел, только набрел на необъятных просторах интранета IBM на описание того, что планируется сделать в светлом будущем из VIOS. Честно - после прочтения первой части началось обильное слюноотделение. Вторая часть его мгновенно прекратила - я прочитал про ограничения Фазы 1. Вторично я вернулся к этому вопросу где-то в октябре-ноябре, когда уже была пора выходить новому VIOS‘у и мне было жутко любопытно, что ж такого там выйдет. К моему величайшему огорчению разработчики VIOS‘а все также планировали включить VIOS NextGen в ближайшую версию, но при этом багтрекер ломился от ошибок, которые по моему скромному мнению были несовместимы с жизнью пациента. Результат известен - VIOS NextGen вышел только в качестве SP1 к VIOS 2.2 и с возможностью создания кластера только из одной ноды. Честно говоря, полнейшее разочарование от технологии, которая должна была стать очередным модным веянием в виртуализации. Но я все-таки порассуждаю на тему, а что было бы, если бы...
Итак, наши системы по известному плану IBM, должны быть уже давно полностью виртуализированы, а это значит, что весь ввод-вывод в них идет через мой любимый VIOS. На настоящий момент для виртуализации дисковой подсистемы у нас есть два варианта: VSCSI и NPIV. NPIV считается более современным и более универсальным - LUN‘ы подключаются напрямую к LPAR‘ам, администратор LPAR‘а «не знает», что они виртуализированы, и может использовать стандартные драйвера от производителя стореджа для MPIO или еще каких-либо дополнительных функций. Дополнительной работы для администратора VIOS практически никакой - только создать маппинг между физическим FC HBA и LPAR‘ом. Зонинг прописывается точно также как и для LPAR‘ов, подключенных через физический FC HBA. И к тому же - практически никакого оверхеда на виртуализацию. Ситуация близкая к идеальной.
VSCSI, наоборот, технология «полной» виртуализации, когда клиент видит не тот LUN, который выделяет администратор стореджа, а некий виртуализированный суррогат, доступный по урезанному подвиду протокола SCSI и с использованием специального драйвера VSCSI (к счастью, он входит в поставку AIX). Соответственно зонинг настраивается между системой хранения и VIOS‘ом, а администратор стореджа ничего не знает про конечного потребителя. И совершенно точно так же в отличие от NPIV здесь требуется больше работы от администратора VIOS и больше места для ошибок. После того, как LUN выделен VIOS‘у, необходимо найти его (а попробуйте найти LUN, если у Вас в VIOS‘е их штук 500 и Вам нарезали еще 20 новых), и правильно смаппить на нужный vhost. Ну и к этому еще прибавляется оверхед на трансляцию из FC в VSCSI. И пусть IBM утверждает, что это практически не заметно, но мы-то знаем...
При всем при этом не является великим секретом, что реализация NPIV в VIOS‘е мягко говоря не самая идеальная - достаточно посмотреть на количество ошибок, которые фиксятся в каждом сервиспаке. Кроме этого многие клиенты отказываются внедрять NPIV из-за проблем с безопасностью данных. Если вы меня спросите - каких, я вам не отвечу. С моей точки зрения VSCSI менее безопасный чем NPIV, но специалистам виднее.
Пораскинув мозгами, светлые головы в IBM придумали замечательную вещь, которая в очередной раз должна спасти мир от всех проблем, а заодно обеспечить рабочими местами десяток безработных админов - VIOS NextGen. Итак в нашем зоопарке есть уже N-ное количество серверов IBM Power, на каждом из которых установлено как минимум 2 VIOS‘а (мы ж Ынтырпрайз, а не в песочнице играем?). Если у нас, предположим, 10 серверов, то это уже 20 VIOS‘ов и куча стореджа, который к ним подключен. Если к каждому из серверов подключено по 100 ГБ стореджа и 90% из него используется, то у нас распределенного между LPAR‘ами, но не используемого места - 180 ГБ. Не очень эффективное использование ресурсов, не правда ли? Я не буду вспоминать, что 90% использования стореджа - очень хороший показатель, и обычно клиенты заказывают себе сторедж с запасом на несколько лет вперед и никогда его не используют. А в этот замечательный момент времени на одном сервере, как всегда жутко важном для бизнеса организации, не хватает места. И как на зло на сторедже тоже место все закончилось - нужно закупать новые диски, либо еще хуже - новый сторедж, а электричества в датацентре на установку очередного бегемота нет и ближайший месяц не будет, пока не будет подписано очередное допсоглашение о выделении еще сотни-другой киловатт на наш любимый датацентр. И тут еще пришли коллеги из отдела тестирования и просят срочно соорудить им тестовую среду точно с такими же данными, как на продуктивной, и нужно еще пару десятков ГБ стореджа, а потом останавливать продуктивную БД и копировать ее на тестовую систему, что потребует очередного RFC, десятки согласований и работу в выходные, которую HR забудет оплатить. Знакомая ситуация? И не надо говорить, что вот у вас все заведено по уму и такого не случается.
Для решения подобных проблем и подходит VIOS NextGen. В идеале все, что требуется сделать, это объединить все VIOS‘ы, которые у вас есть, в один (или несколько) кластеров. После этого сторедж выделяется (настраивается зонинг) на все VIOS‘ы в кластере. Таким образом, на любой машине Вы видите абсолютно все LUN‘ы для всех клиентов. Это, конечно, плохо и небезопасно, но это мы оставим пока за скобками. Из этих LUN‘ов создается пул дисков, из которого в свою очередь выделяются диски клиентам. Им они доступны все по тому же старому протоколу VSCSI. Но на стороне VIOS‘а эти диски становятся thin-provisioned, т.е. клиенту не выделяется сразу же весь запрошенным им объем, а только тот объем, который реально используется. Остальное место остается свободным. Мы получаем некоторую дополнительную свободу в распределении дискового пространства между клиентами и между машинами. Одни и те же диски, входящие в один кластерный пул, могут быть розданы клиентами на десятке различных машин. И за счет thin provisioning‘а мы получаем возможность использовать временно неиспользуемое место для других LPAR‘ов, дожидаясь пока приедет наша очередная DS8000/Hitachi USP/EMC Symmetrix/что-там-еще-мы-хотим-купить. И поскольку весь сторедж кластеризован между всеми машинами, нам нет нужды заботиться о том, на какой из машин требуется сторедж - он там есть. Больше того, нам нет нужды заниматься ре-зонингом, или перенарезанием LUN‘ов - все уже отзонировано заранее и нарезано, осталось лишь выделить сторедж LPAR‘у. Отсюда также вылезает еще одна приятная особенность - Live Partition Mobility становится еще более lively. Поскольку сторедж уже смаппирован на все VIOS‘ы, нет нужды тратить время на проверку, а есть ли там сторедж (он там есть), на перетаскивание WWPN‘ов, на ремаппинг vfchost‘ов, а также страдать, выявляя непонятные ошибки (а Вы видели такую веселую ошибку, когда LPAR уже смигрировал, а на системе-источнике он остается существовать в статусе Migration - Active? И ничего Вы с ним больше не сделаете - только выключать целиком всю машину).
Вторая замечательная особенность - это клонирование стореджа. Нужна Вам новая тестовая среда? Нет проблем! Продуктивная работает на Power 770, а на свободном завалявшемся Power 740 клонируете сторедж для продуктивной среды в новой LPAR (главное, чтобы VIOS‘ы были в том же кластере). При этом, как и полагается, клон занимает места примерно 0,0 ГБ. А зачем жрать нужное и дорогое место, если данные еще не изменены? Вот когда они изменятся, мы используем немного места под лог этих изменений. А пока - переживут тестеры, ничего с ними не случится!
А как Вы делаете бэкап со своей «самой важной» базы данных? Все так же останавливаете всю систему на 5-10 часов? А ведь это простой и деньги Вашей организации. Не будем мелочиться - создадим еще один LPAR, сделаем снэпшот с продуктивной системы и отдадим его R/O новому LPAR‘у, а потом можно будет на новом LPAR‘е делать бэкап ближайшие 23 часа - до нового окна. А "старый" продуктивный будет продолжать работать и обслуживать клиентов.
И то, что когда-то давным давно у меня не получалось со старыми версиями VIOS‘а (а с новыми я не пробовал) - быстрое развертывание AIX. Делаем LPAR, устанавливаем туда эталонный AIX, а затем на уровне VIOS‘а говорим, что вот этот диск, отданный AIX‘у, - это наш имидж, из которого в дальнейшем должны создаваться копии новых дисков под rootvg для всех новых LPAR‘ов. И все. Новый LPAR, почти готовый к работе (нужно только поменять IP-адреса), за 5 минут. Ну или сколько времени у Вас занимает создать новый LPAR в HMC и замаппить на него диски с VIOS‘а.
Вот такая сказка про VIOS, которая могла бы стать былью в конце прошлого-в начале этого года. Надеюсь, что еще станет к концу этого года. Хотя бы частично. Вопросы производительности я оставлю за скобками, потому что пока нет готовой реализации очень сложно рассуждать, насколько весь этот функционал будет тормозить систему. Но то, что он не будет ее ускорять, с моей точки зрения очевидно.