company_banner

Системы хранения данных: как медленно, но верно они отвязываются от железа


    Авария в первом дата-центре и автоматический перезапуск сервисов в другом

    Виртуализация — одна из моих любимых тем. Дело в том, что сейчас можно практически полностью забыть про используемое железо и организовать, например, систему хранения данных в виде «логического» юнита, который умеет взаимодействовать с информацией по простым правилам. При этом все процессы между виртуальным юнитом и реальным железом в разных ЦОДах лежат на системе виртуализации и не видны приложениям.

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

    К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.

    Но давайте начнём с самого начала — как работает виртуализация систем хранения, зачем оно всё надо, и какие задачи решаются. И главное — где конкретно вы сможете выиграть и как.

    Немного истории


    Сначала были сервера с внутренними дисками, на которых хранилась вся информация. Это довольно простое и логичное решение быстро стало не самым оптимальным, и со временем мы стали использовать внешние хранилища. Сначала простые, но постепенно потребовались специальные системы, позволяющие хранить невероятно много данных и давать к ним очень быстрый доступ. СХД отличались друг от друга объёмом, надёжностью и скоростью. В зависимости от конкретных технологий (например, магнитная лента, жесткие диски или даже SSD, которыми сейчас, конечно, никого не удивить) можно было варьировать эти параметры в довольно широком диапазоне — главное, чтобы были деньги.

    Для ИТ-директоров сейчас один из самых главных критериев СХД — надёжность. Например, час простоя для банка вполне может стоить как 10-20 таких шкафов с железом, не говоря уже о репутационных потерях — поэтому основной парадигмой стали географически распределенные отказоустойчивые решения. Проще говоря – железки, дублирующие друг друга, которые стоят в двух разных дата-центрах.

    Эволюция:


    I ступень: Два сервера со встроенными дисками


    II ступень: СХД и две машины в одном ЦОДе.


    III ступень: Разные ЦОДы и репликация между ними (самый распространенный вариант)


    IV ступень: Виртуализация этого хозяйства. Кстати, в связку в середине можно воткнуть, например, дополнительно резервное копирование.


    V ступень: Виртуализация СХД (EMC VPLEX)

    Один из инструментов решения такой задачи – EMC VPLEX, на примере которого можно чётко понять плюсы этой самой виртуализации.

    Сравнение систем


    Так в чем же суть?

    До VPLEX: есть два сервера, каждый видит свой том, между томами репликация. Один всегда стоит и ждёт, второй всегда работает. Резервный сервер не имеет прав на запись, пока не отказал основной ЦОД
    После внедрения VPLEX: репликация не нужна. Оба сервера видят только один виртуальный том, как подключенный напрямую к себе. Каждый сервер работает со своим томом, и каждый думает, что это локальный том. В реальности каждый работает со своей СХД.

    До: для переноса данных на другое хранилище (физическую СХД), нужна перенастройка серверов, кластеров и так далее. Это снижает отказоустойчивость и может стать причиной ошибок: при переконфигурации кластер может разъехаться, например.
    После: можно без снижения отказоустойчивости и прозрачно для серверов перенести данные (все СХД скрыты под VPLEX и сервера про железо даже не знают). Механика такая: добавляем новую СХД, подключаем её под VPLEX, зеркалируем, не убирая старую, потом переключаем – и сервер даже не замечает.

    До: есть проблемы с разными вендорами, например, нельзя настраивать репликацию HP с массивом EMC.
    После: можно подключить массив HP и EMC (или других производителей) и спокойно из двух стораджей собрать том. Это особенно круто, потому что у крупных заказчиков часто гетерогенный «зоопарк», который плотно интегрируется и легко модернизируется. Это значит, что любую критичную систему можно легко и просто перенести на новое железо без сопутствующей головной боли.

    До: нужно время на переключение репликации и кластера.
    После: перезапускается только приложение в кластере, оно всегда либо на одной ноде, либо на второй, но прозрачно и быстро перебрасывается.

    До: архитектура — геокластер со всеми ограничениями.
    После: архитектура – локальный кластер. Точнее, сервер так думает, и поэтому нет никаких сложностей в работе с ним.

    До: необходимо ПО управления репликацией.
    После: VPLEX на системном уровне следит за репликацией. Да и вообще, репликации, по сути, нет – есть «зеркало».

    До: SRM накладывает свои ограничения на перезапуск VM в резервном ЦОДе.
    После: стандартный VMotion работает при перемещении ВМ на резервную площадку (предваряя вопрос про канал: да, у нас широкий канал между площадками, так как мы говорим о серьёзном Disaster Recovery решении).

    Как переезжать без простоя системы?


    Переезжать с одной железки на другую приходится довольно часто: примерно раз в два-три года высоконагруженные системы требуют модернизации. В России реалии таковы, что многие заказчики просто боятся трогать свои системы и плодят «костыли» вместо переноса — и часто вполне оправданно, потому что примеров ошибок при переезде тоже много. С VPLEX переезжать просто — главное, знать про такую возможность.

    Ещё один интересный момент — это перенос систем, по которым производительность непонятна. Например, банк запускает новый сервис, и его наличие становится через полгода важным конкурентным преимуществом. Нагрузка на железо растёт, нужно делать сложный и мучительный переезд (банки боятся даже одной потерянной транзакции, и даже 5 миллисекунд промаха — это проблема). В этом случае VPLEX-подобные системы становятся единственной более-менее разумной альтернативой. Иначе быстро и прозрачно подменить СХД будет непросто.

    Допустим, система старая и жестко привязана к железу. При переезде на другое железо нужна среда, которая поможет осуществить перенос без влияния на работу пользователей и сервисов. Поместив такую систему под VPLEX, ее можно будет легко переносить между вендорами — приложения даже не заметят. С поддержкой ОС проблем также не возникает. В списке совместимости все основные операционки, встречающиеся у заказчика. В экзотических случаях, можно проверить совместимость с вендором или партнером и получить подтверждение.



    Берём действующую систему СХД (слева) и зеркалируем средствами EMC VPLEX незаметно для сервера и приложений(справа). В терминах VPLEX это называется Distributed volume. Сервер продолжает думать что работает с одним стораджем и одним томом.



    Фактически, первая СХД становится чем-то похожим на кусок зеркала. Её мы отключаем — и переезд готов.

    Про синхронизацию


    Есть три конфигурации – Local (1 ЦОД), Metro (синхронная репликация) и Geo (2 асинхронных ЦОД). Разновидность синхронной репликации с x-подключением – Campus. Синхронная репликация наиболее востребована (это 99% внедрений в России). Здесь в дело вступает бессердечная скорость света, которая устанавливает максимальное расстояние между ЦОДами — должно хватить 5 миллисекунд на прохождение сигнала. Можно настраивать и с 10 миллисекундами, но чем ближе ЦОДы — тем лучше. Обычно это 30-40 километров максимум.


    Варианты схемы для синхронной репликации

    VPLEX даёт серверам доступ на чтение-запись. Серверы видят один том данных каждый на своей площадке, но на деле это виртуальный распределённый том VPLEX. Metro позволяет большие задержки, Campus даёт большую надёжность. В Campus это выглядит так:


    Самое приятное — никаких проблем с переключением репликации при перемещении виртуальных машин.



    При использовании Campus отказ всех дисковых подсистем и локальной части VPLEX приведет к потере только половины путей для диска. Сами же диски останутся доступны серверам – только уже через x-подключение и удаленную часть VPLEX. Вот как это работает для Oracle.

    Есть ещё ситуации типа ЦОДов в Москве и Новосибирске, они решаются асинхронной репликацией. Её VPLEX тоже умеет, но уже в конфигурации Geo.

    А если авария?




    Здесь VPLEX Metro и VMware HA (но может быть и Hyper-V) — и авария в одном из ЦОДов.


    Сервисы перезапускаются в другом ЦОД без участия администратора, т.к. для Vmware это единый HA кластер.

    В середине есть Witness — это виртуалка, которая контролирует состояние обоих кластеров и следит, чтобы при разрыве связи между ними оба не начали обрабатывать данные. То есть защищает от машинной «шизофрении». Witness позволяет в случае аварии работать с наиболее актуальной копией только одному кластеру — и после устранения проблемы второй просто получает более свежую версию данных и продолжает работать.

    Witness разворачивается либо на третьей площадке, либо у облачного провайдера. Она коммуницирует с EMC VPLEX по IP посредством VPN. Больше ей ничего для работы не нужно.

    Данные на удалённой площадке


    Получить данные, физически расположенные в другом ЦОДе — также не вопрос. Зачем? Например, если в основном ЦОДе не хватает места. Тогда можно занять его в резервном.

    Гетерогенное железо




    Экосистема «VPLEX и партнеры»

    В центре решений КРОК на базе технологий EMC мы построили такое решение. На одной площадке СХД EMC, сервера Cisco (для многих новость, что Cisco выпускает весьма хорошие сервера), на другой площадке виртуализована система Hitachi, а сервера IBM. Но как видите, все остальные вендоры тоже спокойно поддерживаются. На той неделе мы проводили демонстрацию системы для одного из банков, для которого и был собран стенд, и их специалисты сами убедились, что косяков нет, и интеграция реально гладкая. В ходе демонстрации мы имитировали различные аварии и сбои, которые мы заготовили, либо заказчик их предлагал по ходу встречи. Следующий этап – пилотный проект на нескольких небольших системах. Несмотря на наличие уже опыта эксплуатации этих железок, каждый заказчик хочет убедиться сам, что все работает. Центр решений сделан именно для этого, так что мы не против.

    Ещё бонусы


    • При работе в одном ЦОД, VPLEX ещё и решает задачу по зеркалированию внутри этого ЦОДа. Кроме того, VPLEX гораздо мягче относится к просчётам в требуемой производительности — можно по ходу пьесы переехать на более мощную СХД.
    • Имея мощности в удалённом ЦОД, хочется их использовать — можно использовать «резервный» ЦОД для СХД в ряде случаев, при этом держать сервера на вашей площадке.

    Как работает доступ к данным?


    Наверняка вам уже интересно, как же это работает уровнем ниже. Итак, раньше при записи на одной площадке и чтении с другой был шанс попасть на неактуальные данные. В VPLEX есть система каталогов, которая показывает, на какой ноде данные наиболее свежие, поэтому кэш-память можно считать общей на всю систему.


    При чтении только что записанного другой машиной участка работает вот такая связка.

    Конфигурация





    Можно начать с малого, например, поставить блок, который содержит 2 контроллера (то есть это уже отказоустойчивая конфигурация, до 500 000 iops) — дальше можно перейти к средней конфигурации или достичь максимальной 4-узловой конфигурации в стойке в каждом из ЦОД. То есть до 2.000.000 iops, что не всегда нужно, но вполне достижимо. Можно пойти дальше и создавать домены VPLEX, но до этого на нашем рынке еще, думаю, никто не дорос.

    Плюсы и минусы


    Минусы:
    • Нужны затраты на внедрение и лицензии
    • Нужно принять решение о переходе на новую философию и обучить персонал
    • Скорее всего, процесс перехода будет поэтапным (но вспомните как мы виртуализировали наши сервера!)


    Плюсы:
    • Можно отвязаться от железа и не заботиться об отказах частей системы, получая надёжность в пять девяток.
    • Простое масштабирование и переезды.
    • Простые манипуляции с виртуальными машинами и приложениями.
    • Нет проблемы мультивендорности.
    • Система с определённого уровня дешевле кучи софта для решения локальных задач СХД в ЦОДах.
    • Благодаря простоте и прозрачности всех действий использование VPLEX существенно снижает количество ошибок человека.
    • Прощает неточные прогнозы по производительности.
    • VPLEX позволяет не думать о затачивании железа под конкретную задачу, а использовать его так, как хочется.
    • Переход от отказоустойчивости к мобильности
    • Администраторы серверов настраивают кластеры как и раньше, используя те же инструменты.


    Внедрение


    Если вы хотите попробовать или посмотреть на то, как всё это работает вживую — пишите на vbolotnov@croc.ru. И ещё я отвечу на любые вопросы в комментариях.
    КРОК
    IT-компания

    Комментарии 42

      0
      Можно хоть примерно обозначить стоимость софта и лицензий?
        +2
        Нет .:)
          +3
          Нужно понимать, что это не только софт и лицензии. Это по стойке минимум в каждом из двух ЦОДов. И железо в этих стойках — только под задачу виртуализации сети хранения. Такое решение на несколько сотен виртуальных серверов стоит около полумиллиона долларов, но зато очень сильно режет расходы на покупку репликации, кластерных лицензий и так далее, не говоря уже о сокращении времени простоя и других плюсах виртуализации в целом. Проще говоря, если ваши расходы на простой или неполное использование ресурсов больше стоимости софта, лицензий, железа и места в ЦОДах — то решение будет выгодным. Или если вы оцениваете потери от аварии или неправильного переезда в достаточно большую часть этой суммы.
            0
            Спасибо, я услышал что хотел ))
            0
            deleted глупость сказал, больше не буду.
            0
            1. Где нагрузочные тесты?
            2. Блок «до и после» не показывает ничего уникального. Это есть есть в других продуктах, за меньшие деньги. Нет?
              0
              1. Нагружали виртуалками на 50 000 iops, но уперлись в производительность систем хранения, VPLEX при этом был загружен где-то процентов на 20. Это вдобавок к нескольким реальным внедрениям, в одном из которых заказчик (сфера телерадиовещания) ставил жесточайшие требования по отказоустойчивости ввиду невозможности прерывать эфиры ни на секунду даже в случае отказа ЦОД.

              2. Уникальность в целостности решения. VPLEX виртуализует СХД различных производителей, работает с большинством ОС и приложений прозрачно для администраторов. Другие продукты дадут вам что-то из этого, но со временем есть риск потерять контроль над «зоопарком». Это ощущается начиная с определенного уровня сложности инфраструктуры компании.
                0
                Другие продукты дадут вам что-то из этого

                А как же NetApp MetroCluster?
                Чем решение VPLEX лучше MetroCluster?
                  0
                  Простите, промахнулся веткой, ответ ниже. Немного разные классы решений.
                    0
                    Давайте тогда ещё IBM SVC помянем.
                    +1
                    >Уникальность в целостности решения. VPLEX виртуализует СХД различных производителей
                    NetApp — V-Series
                      0
                      > Уникальность в целостности решения. VPLEX виртуализует СХД различных производителей, работает с большинством ОС и приложений >прозрачно для администраторов.

                      Это сейчас не делает только ленивый. Netapp V-Series, IBM SVC, Storwise, ну и собственно Hitachi VSP.
                      Ну и уж если говорить о виртуализации СХД, как раз у Hitachi она появилась впервые.
                    +1
                    хм, а не становиться ли эта система сама по себе точкой отказа? я правильно понимаю и вся связь с СХД идет через эту самую систему? И если у нас 1 цод, и выключилась эта стойка с VPLEX, то все рухнуло с громким звуком (несмотря, что все СХД живы)?
                      0
                      С одним ЦОДом всегда не так чудесно. Но, допустим, что выключилась именно стойка с VPLEX. Достаточно перебросить дисковые тома «напрямую», т.к. сам VPLEX не вносит никакой служебной информации и не меняет формат ее хранения. Однако, практика показывает, что скорее выключится весь ЦОД.
                      0
                      а сам VPLEX может работать в кластере, находясь в разных ЦОДах?
                        0
                        Да, находясь в разных ЦОД, он дает возможность читать и записывать данные в обоих ЦОД, следя за их целостностью, т.е active/active кластер. Это очень полезная функция, позволяющая, например, не просто держать резервный ЦОД, а полностью использовать его мощность.
                          0
                          упс, выше ответили уже
                          +1
                          Точно отказываются, уже даже появляются виртуальные СХД %)
                          NetApp Data ONTAP Edge…
                            0
                            HP VSA, VMware VSA, StarWind и всякое такое :) Только это все детские шалости, по сравнению с реальными монстрами рынка СХД, об отказе говорить ещё ой как сложно.
                              0
                              Действительно, NetApp MetroCluster схоже с EMC VPLEX, но оно немного другого класса. VPLEX масштабируется до 8 контроллеров в каждом ЦОД. В решениях уровня Enterprise двух контроллеров NetApp может быть просто недостаточно. К тому же, по слухам, в мае нас ждет релиз версии VPLEX, организующей синхронный доступ более, чем в двух ЦОД.
                                0
                                Да я не про MetroCluster :)

                                Нетап выпустил виртуальную машину в виде виртуал аплаенса.
                                Работает под ESXi и Hyper-V. Внутри неё операционка, почти со всеми фишками что и у реальной железяки NetApp FAS. Но только это виртуальная машина!
                                  0
                                  Ну а в чём прикол-то в этом для людей? Ну вот по-вашему лично мнению, кроме того, что это просто круто иметь «почти настоящий netapp» в виртуалке :)
                                    0
                                    Ну а в чем смысл для людей, упомянутой вами же HP VSA?
                                    По сути NetApp софтверная компания и они об этом прямо заявляют. Железо под свои хранилки они оемят. Для малого бизнеса вполне себе решение купить сервер с большим количеством дисков и развернуть на нем NetApp Edge. Многие хотят экономить и идти на риски, используя самосборные СХД.
                                    Тот же LeftHand до покупки HP продавался на серверах разных производителей — IBM, HP, может еще кто-то.

                                    Но в любом случае это решения совсем не сравнимы с EMC VPLEX и NetApp FAS/V 6000-серии.
                                      0
                                      Ну а в чём смысл упомянутой мной же HP VSA? Вот я и bbk и спрашивал в чём смысл. А делал я это не потому что не понимаю, в чём он :) а потому что хотел его ответ, как говорится «использовать против него в суде».
                                        0
                                        А чье железо, говорите, OEM-ит NetApp? :)
                                          0
                                          Про NetApp я спросил в том ключе, что сейчас все вендоры в той или иной мере кого-то OEM-ят.
                                          Кто-то свои ASIC делает, вроде HDS, кто-то делает все software-oriented, как NetApp, диски у всех все равно от Seagate и Hitachi.
                                          А IBM OEM-ит NetApp, HP — HDS, и так про кругу :)
                                            0
                                            Конечно все OEM-ятся. Куда уж без этого. Просто кто-то может делать вид, что это не так :)
                                            Полки у NetApp однозначно от Xyratex.
                                              0
                                              Да-да, про полки совершенно с вами прав :)
                                              Я думал вы все компоненты имеете ввиду, потому что про контроллеры информации о OEM не встречал никакой.
                                                0
                                                Где-то на blog.aboutnetapp.ru встречал, кажется в коментах писали, кто контроллеры NetApp'у проектирует.
                                              0
                                              Да не, оемятся не все :) Сейчас как-то все потихой сливают OEMные линейки — IBM не сильно гонит желанием Netapp продавать, что N-серию, что DS'ки хочет на свои сторвайзы заменить. HP тоже Хитачи продаёт только по старой памяти и активно двигает свой 3par (полки которого, как и у сторвайза очень похожи на Xyratex ^_^). А вот то, что производят всё на одних и тех же заводах по контрактам — это другое дело.
                                            0
                                            Не вдаваясь в технические детали: Компания решила выпустить такой продукт и кстати говоря он не бесплатный. По-видимому они думают, что пользователям это может пригодиться, что те станут за него платить деньги…

                                            Но основной смысл моего поста в том, что предположение автора поста «Системы хранения данных: как медленно, но верно они отвязываются от железа» имеет место на существование, это подтверждается фактом наличия «netapp в виртуалке».
                                              0
                                              Компания решила выпустить такой продукт и кстати говоря он не бесплатный. По-видимому они думают, что пользователям это может пригодиться, что те станут за него платить деньги

                                              То есть компания решила и всё, это уже аргумент за точку зрения «системы хранения отвязываются от железа»? А каким таким образом будет осуществляться хранение данных в виртуальном онтап эдже без железа? :)
                                                0
                                                Лично я решений никаких не принимал, а принимала компания нетап. Как вам известно компания не за бесплатно работает это комерческая структура и похоже, что люди в ней работающие считают имеющйся функционал достойный для продажы и существования.
                                                Почему? Это опять не комне вопрос.

                                                Но суть в том, что к примеру 5-ть лет тому назад такого небыло а теперь есть.

                                                Если вам действительно интересно какие есть технические фичи в NetApp Data ONTAP Edge и как это применять, я бы предложил вывести такой разговор из глубокого офф-топика к этой статье и обсудить это в другом месте.
                                                  0
                                                  и похоже, что люди в ней работающие считают имеющйся функционал достойный для продажы и существования.

                                                  Ну да, только это решение продаётся не как «новейшее достижение, то куда идёт индустрия СХД — виртуализация! Очевидно, что СХД медленно, но верно отвязываются от железа, вот наше решение», а как «У вас нет денег на полноценное решение, но фичи хочется? Или нужно поставить в мелкий офис хоть что-то и пользоваться нашими фичами? Вот пожалуйста, наше виртуальное решение для бедных».
                                                    +1
                                                    Уважаемый Сергей, действительно это решение для тех у кого денег не много — на удалённые офисы, а не решение «само по себе». По-поводу того, что решение движится не туда куда движется индустрия это вы загнули.
                                                    Люди делают не малые деньги на этом бизнесе и я думаю они уж лучше меня или вас понимают куда движется индустрия.

                                                    Ещё раз прошу вывести этот разговор куда-то, к примеру в личную переписку.
                                                    Мы уже в глугоком офтопике.
                                          0
                                          Я что-то про синхронный доступ никак не пойму, что вы называете синхронным доступом?
                                        0
                                        2 BoVados:

                                        Можно поподробней про иопсы: какая латенси и какой патерн нагрузки для указанных величин?

                                        Прочитав текст, похоже я неправильно понял его
                                        После внедрения VPLEX: репликация не нужна. Оба сервера видят только один виртуальный том, как подключенный напрямую к себе. Каждый сервер работает со своим томом, и каждый думает, что это локальный том. В реальности каждый работает со своей СХД.

                                        Потому что дальше на картинке я увидел «Свидетеля». А зачем он тогда нужен, если том итак один?
                                          +3
                                          Свидетель разговаривает с обоими Vplex'ами и утешает их в случае если они перестали друг друга видеть из-за каких-то проблем на линии, а потом, когда всё восстановится, он говорит кто главный и чьи данные нужно реплицировать. Том один для серверов, а уровнем ниже это всё равно два тома.
                                            0
                                            Пардон, но по-мне так это ещё одни грабли да ещё какие, наверно в таком случае лучше иметь второй том только для чтения.
                                            Вот к примеру разорвалась связь, СХД «утешены», а кто утешит приложения? Это ж разрыв мозга.
                                              +1
                                              Насколько я понимаю процесс, если связь разорвана и СХД «утешены», то одна из них становится мастером и продолжает писать данные, а вторая перестаёт и говорит своим серверам отбой, те ложатся спать и пользователи продолжают работать с живой половинкой. На серверах ведь всё равно нужно будет ставить какой-то кластерный софт для того, чтобы писать в один том, неважно в одной СХД он находится или в разных цодах, поэтому отвал одной схд приведёт к штатной остановке работы всей половинки.
                                                0
                                                Да уж, эволюция что называется в натуральном виде.

                                                Или мы с вами чего-то не знаем, или «V ступень» от «IV ступень» о которых говорит автор, отличается не в лучшую сторону.
                                                0
                                                Точно подмечено, разрыв мозга. Даже термин как раз есть — split brain

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое