21 Replies Latest reply: Feb 20, 2013 10:28 PM by ALEXGOLYSHEV RSS

объединение доступного пространства 2 контроллеров

ALEXGOLYSHEV
Currently Being Moderated

Добрый день, уважаемое сообщество!

С недавнего времени наша организация стала обладателем системы хранения FAS 2220a. Данного зверя свесли на меня, человека первый раз увидевшего подобный девайс. С самого начало наша дружба не особо задалась, жаловался на проблемные вентиляторы, с этим разобрались, все, можно приступать к настройке, а тут уже не хватает даже  первоначальных знаний. Были изучены мануалы, написанные Романом Хмелевским, за это ему отдельное огромное спасибо! Но как я понял 3 часть замечательных howto так и не появилась в свет.

Это лирическое отступление. На практике же, вышеописанный зверь подразумевается использовать в связке с CitrixXenServer-ом. Первым же вопросом, смею спросить вас, если система двухконтроллерная, а диски разделены между ними поровну, возможно ли каким-либо способом объединить на логическом уровне пространство для данных? Или же придется к Xen-у подключать 2 SR от каждого контроллера?

 

 

  • Re: объединение доступного пространства 2 контроллеров
    GERA.SUKHOV
    Currently Being Moderated

    Именно так, 2 SR. Или сделать неравномерное разбиение дисков между контроллерами в надежде на то, что в дальнейшем подключите дополнительную полку к незагруженному контроллеру.

    • Re: объединение доступного пространства 2 контроллеров
      ALEXGOLYSHEV
      Currently Being Moderated

      Спасибо!  Тогда такой вопрос, если я делаю один контроллер более загруженным, второй как понимаю будет находиться в резерве. Соответственно если это так, во время поломки загруженного контроллера, должен его роль принять на себя живой. Так ли это? + Мне до сих пор так и не встречалось какое-либо описание переноса винтов между контроллерами, это осуществляется физическим переключением или с помощью консоли?

      • Re: объединение доступного пространства 2 контроллеров
        aborzenkov
        Currently Being Moderated

        Это осуществляется автоматически и вам ничего делать не надо. Если все остальное правильно настроено ☺

      • Re: объединение доступного пространства 2 контроллеров
        GERA.SUKHOV
        Currently Being Moderated

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

      • Re: объединение доступного пространства 2 контроллеров
        ABOUTNETAPP.RU
        Currently Being Moderated

        Alexey Golyshev wrote:

         

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

        Это возможный вариант, но учтите, что в этом случае вы платите за два контроллера, за два процессора, за в два раза больший объем памяти и за двойной комплект лицензий, а используете при этом только половину. Неэкономичненько. Так уж вам надо иметь один массив дисков "единым куском"? На практике достаточно обычная ситуация, когда на массиве хранятся различные задачи, например множество вироуальных машин, которые достаточно несложно раскидать примерно поровну по двум контроллерам.

        • Re: объединение доступного пространства 2 контроллеров
          GERA.SUKHOV
          Currently Being Moderated

          Так уж вам надо иметь один массив дисков "единым куском"? На практике достаточно обычная ситуация, когда на массиве хранятся различные задачи, например множество вироуальных машин, которые достаточно несложно раскидать примерно поровну по двум контроллерам.

          Раскидывать по двум контроллерам только чтобы использовать второй комплект лицензий - сомнительная экономия. Это скорее из разряда "если не съесть, то хоть понадкусывать". А вот потеря usable space вполне существенная. Во первых - за счет hot spare для второго контроллера, во вторых - за счет меньшего коэффициента экономии от дедупликации из-за разных томов.

          • Re: объединение доступного пространства 2 контроллеров
            ABOUTNETAPP.RU
            Currently Being Moderated

            А почему вы из длинного-длинного перечисления выхватили только это?

            • Re: объединение доступного пространства 2 контроллеров
              GERA.SUKHOV
              Currently Being Moderated

              Т.е. Вы считаете, что цитату где Вы говорите про два (процессора, память, лицензии) я просто опустил?

              Во первых - я упомянул, что это сомнительная экономия. Во вторых - горячая замена - это не значит не использовать. Например оплата идет за все диски, но используете же hot spare! Вы же сами писали - это не недостаток, а свойство!

              Ну и в третьих, я не вижу особого смысла в дискуссии что лучше "Active-Active" или "Active-Passive", а указать где и что теряется. Выбирать конфигурацию то не мне...

              • Re: объединение доступного пространства 2 контроллеров
                ABOUTNETAPP.RU
                Currently Being Moderated

                Т.е. Вы считаете, что цитату где Вы говорите про два (процессора, память, лицензии) я просто опустил?

                 

                Очевидно что так, иначе утверждение выше не имеет смысла.

                 

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

                Впрочем, винить за такое надо не его, а партнеров в интеграторе, которое такое продали не объяснив, как я понимаю, все catches такой конфигурации.

        • Re: объединение доступного пространства 2 контроллеров
          ALEXGOLYSHEV
          Currently Being Moderated

          Roman Hmelevsky wrote:

           

          Это возможный вариант, но учтите, что в этом случае вы платите за два контроллера, за два процессора, за в два раза больший объем памяти и за двойной комплект лицензий, а используете при этом только половину. Неэкономичненько. Так уж вам надо иметь один массив дисков "единым куском"? На практике достаточно обычная ситуация, когда на массиве хранятся различные задачи, например множество вироуальных машин, которые достаточно несложно раскидать примерно поровну по двум контроллерам.

          Согласен с вами, экономии в таком случае мало да и машины вполне можно раскидывать по SR. Но радует при этом что второй комплект бережет моё спокойствие в случае вылета первого контроллера, этим наверно экономия примерно уравнивается. Заметна ли будет разница в производительности если все операции будет тянуть один контроллер, а второй только добавлять уверенности в случае вылета?

          GERA.SUKHOV wrote:

           

          Раскидывать по двум контроллерам только чтобы использовать второй комплект лицензий - сомнительная экономия. Это скорее из разряда "если не съесть, то хоть понадкусывать".  А вот потеря usable space вполне существенная. Во первых - за счет hot spare для второго контроллера, во вторых - за счет меньшего коэффициента экономии от дедупликации из-за разных томов.

          В моем случае, наличия всего 12 дисков, hot spare + parity здорово жадность поджимает.

           

           

          Кстати, а сколько придется оставить дисков на резервном контроллере, если при придется? 

           


          • Re: объединение доступного пространства 2 контроллеров
            ABOUTNETAPP.RU
            Currently Being Moderated

            Согласен с вами, экономии в таком случае мало да и машины вполне можно раскидывать по SR. Но радует при этом что второй комплект бережет моё спокойствие в случае вылета первого контроллера, этим наверно экономия примерно уравнивается.

            Не понял этого вывода, что где уравнивается?

            Заметна ли будет разница в производительности если все операции будет тянуть один контроллер, а второй только добавлять уверенности в случае вылета?

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

            Пример - random-операции ввода-вывода, объемом значительно превосходящие объемы кэша, и делающие постоянный cache miss, или чтение большими блоками по одному только порту контроллера.

            В противном случае может так статься, что уполовиненный кэш и уполовиненная мощность процессоров съест все преимущества длинной RAID-группы.

             

            Кстати, а сколько придется оставить дисков на резервном контроллере, если при придется?

            Минимум один aggregate из минимум одной RAID-группы, то есть трех дисков для RAID-DP или двух для RAID-4, плюс один spare (если не отключать варнинги о его отсутствии).

            • Re: объединение доступного пространства 2 контроллеров
              ALEXGOLYSHEV
              Currently Being Moderated

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

               

              Не понял этого вывода, что где уравнивается?

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

              • Re: объединение доступного пространства 2 контроллеров
                ABOUTNETAPP.RU
                Currently Being Moderated

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

                Это вопрос не так прост, как кажется.

                Также как скорость эскадры определяется скоростью самого медленного в ней корабля, также и надежность пределяется уровнем надежности самого ненадежного компонента IT-системы.

                Уверены ли вы, что увеличиваете надежность самого ненадежного компонента инфраструктуры (в данном случае стораджа)?

                Все остальные проблемы с (не)надежностью в инфраструктуре решены? Сетевые компоненты, свитчи, кабеля уже сделаны dual path? Все сервера такжеработают в конфигурации отказоустойчивого кластера? Все блоки питания их сдублированы и включены в разные линии питания от разных поставщиков?

                 

                Даст ли вложение средств в затраты на увеличение надежности экономически адекватную отдачу?

                Вот смотрите, на территорию России падают метеориты ;-) Вполне логично, что следует застраховаться от падения метеорита. Однако практика показывает, что крупные метеориты на территорию России падают в среднем раз в сто лет. Конечно можно пойти и заплатить денег в качестве страховки от падения метеорита, но эти же деньги можно потратить с большей отдачей и не особенно снижая риски, отказавшись на ближайшие сто лет от страхования от падения метеорита (а наоборот, побольше вложив в страхование от лесных пожаров и наводнений, например).

                 

                Сходная ситуация и тут. Да, конечно, отказоустойчивая конфигурация контроллеров это хорошо, само по себе. Но надежность не существует "сама по себе", у нее есть всегда некая составляющая "экономической эффективности".

                Вот я, например, крайне редко видел отказы контроллеров (а вот отказы жестких дисков случаются ежегодно, я тут как-то даже опрос делал, помнится).

                Это не значит, что дублирование контроллеров совсем не нужно. нужно. Но когда у вас стоит вопрос страховаться от падения метеорита, или от чего-то более реального, то я бы предпоел тратить деньги на более реальные угрозы. Хотя, конечно, метеориты иногда падают :-)

          • Re: объединение доступного пространства 2 контроллеров
            GERA.SUKHOV
            Currently Being Moderated

            Лично мое мнение, с которым, возможно, многие не согласятся, что в случае конфигурации "Active-Passive" для второго контроллера оставить только 2 диска (RAID-4) без hot spare. Таким образом все остальные диски можно отдать первому контроллеру (9-RAID-DP + 1 hot spare).

            Что касается производительности, то это, на мой взгляд, один из решающих факторов выбора той или иной конфигурации. Если один не потянет, то без вариантов надо использовать два. Однако, в этом случае, не надо себя обольщать, что при выходе одного из контроллеров все будет зашибись. Остается то один контроллер, который все и должен тянуть... И тут играет большое значение увеличение латентности запросов к СХД. Могут быть ситуации, когда увеличение этого времени свыше определенного порога приведет к развалу. Я с этим столкнулся один раз... Правда СХД, в том случае, была ни при чем.

            Резюме.

            Если при работе на одном контроллере все работает приемлемо быстро, то можно использовать конфигурацию "Active-Passive" и ждать добавочной полки. Если один контроллер явно не справляется, то только "Active-Active" и подготовится в аварийных режимах к тому, что придется принудительно снижать нагрузку. Например уменьшать количество работающих виртуалок.

  • Re: объединение доступного пространства 2 контроллеров
    ALEXGOLYSHEV
    Currently Being Moderated

    Резюмируя все выше сказанное:

    Как говорится: "В споре рождается истина". Решил прикрыть глаза на собственную жадность в использовании контроллера в Active-Passive и расширения используемого пространства. Думаю и в правду будет более целесообразно использовать все технические возможности имеющейся системы. Тем более в случае разнородности виртуальных машин находящихся на Xen-е.

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

     

More Like This

  • Retrieving data ...