Главная Storages, Новое Fibre Channel, iSCSI, NAS, NetApp, SAN
  • NAS & SAN

    Kids__6_Bin_Storage_Drawer NAS – Network-attached Storage, «устройство хранения, подключенное к сети» и SAN – Storage Area Network, «сеть хранения данных» – это не просто «переставленные в разном порядке буквы»;), это две концепции организации и использования сетевого хранения данных.
    Часто приходится сталкиваться с принципиальным непониманием у клиентов разницы между NAS и SAN-подключением внешнего дискового массива, преимуществах и недостатках каждого из вариантов.
    Итак,  давайте вкратце, не влезая в дебри и частности, разберемся что есть что, чем отличается друг от друга и какие плюсы-минусы есть у каждого.

     

  • Главная Storages, Новое NetApp, Storages
    • Silent Data Corruption – неотслеженное повреждение данных

      DataCorruption Без технологии защиты, действующей “от двери и до двери”, повреждение данных может пройти незамеченным, и тогда процесс восстановления окажется длительным, трудным и дорогостоящим, если и вообще возможным. Без технологии проверки целостности данных на всем протяжении пути данных, такое необнаруженное повреждение может вести к неожиданным и трудноотлавливаемым проблемам.Недавняя статья в PC Magazine (опубликована 25 августа 2008 года) сообщает о произошедшем в реальной жизни инциденте:

    • Главная Storages, Новое Fibre Channel, iSCSI, Storages, мысли
      • Кризис – время искать оптимальные решения. Часть 2

        EMOTICON MONEY Почти всегда, начиная разговор с клиентом по поводу использования iSCSI вместо Fibre Channel, раз за разом я сталкиваюсь с одним упорным возражением:
        “Ну… хм… Это же медленно!”
        Ну, казалось бы, очевидно: FC это 4Gb/s, а iSCSI – 1Gb/s, “один” ведь в четыре раза меньше, чем “четыре” ведь так?
        Давайте разберем что здесь на самом деле “медленно” и медленно ли.
        Для определенности давайте рассматривать какую-нибудь реальную задачу.

        Вот пример:
        Требуется система хранения данных для консолидации данных 4 серверов, 1 файловый сервер и 3 сервера баз данных. Необходимо обеспечить двухпутевое отказоустойчивое подключение.

        Но сперва немного теории.
        Я уже писал на тему странного спутывания в восприятии совершенно разных параметров канала передачи данных: “полосы пропускания” (анг. “bandwith”) и “скорости” (анг. “speed”).
        Для интересующихся подробностями просто сошлюсь на ранее опубликованный пост, а остальным перескажу вкратце.

        “Скорость” канала передачи данных равна скорости света в соответствующей среде, и она постоянная, вне зависимости, используем мы 10Mb/s Ethernet или 16GB/s Infiniband.
        Переводя на аналогии из “повседневной жизни” это ограничение скорости на дороге – 100 km/h.
        Все автомобили по дороге передвигаются с разрешенной скоростью, и ее не превышают по причине физического ее ограничения на уровне физических констант.

        В чем же отличие?
        В полосе пропускания.
        Полоса пропускания – это “рядность автострады”, это способность пропустить через себя “много данных” сразу. Но многорядность автострады никак не ускоряет движение одинокого автомобиля, проезжающего раз в минуту.
        Несколько парадоксальный вывод, который я делал в том посте требует некоторого волевого усилия для осознания.

        Неважно, насколько “быстрым” (с какой ширины полосой пропускания) интерфейсом соединена ваша система хранения с сервером, если объемы обработки данных этим сервером не достигают потолка имеющейся полосы пропускания.
        Если скорость считывания и записи сервера с системы хранения, например, не превышают 10 Мбит/с, то совершенно неважно для быстродействия, используете ли вы 100Mbit/s Fast Ethernet, FC, Infiniband, или подставьте_любой_баззворд_из_презентации.

        Если вы не используете даже имеющуюся полосу пропускания целиком, то расширение ее “неиспользуемой части” в 10 раз не приведет к сколь-нибудь значимому увеличению реального быстродействия системы.

        Да, я знаю про разницу в латентности разных интерфейсов, о перспективности того или иного решения в будущем, о функциональных возможностях, давайте не станем углубляться в детали для того, чтобы рассмотреть лес за деревьями, именно он в данном случае важен, а не теоретические вариации, укладывающиеся в статистический разброс 5%

        Вернемся к нашей практической системе хранения для 4 серверов.
        В ходе предварительного анализа производительности, наиболее нагруженный сервер баз данных показал, по данным Windows Performance Monitor, следующие показатели:

        Disk Read bytes/s 2700902/Average 63587550/Max
        Disk Write bytes/s 736811/Average 1616167/Max

        То есть, самый нагруженный сервер системы, в максимуме нагрузки, достигал порога чтения всего, примерно, в 60-65 мегабайт в секунду!
        Это всего лишь (в пике дневной нагрузки, прошу заметить!) около 55-60% от полосы пропускания одного интерфейса Gigabit Ethernet, или, в случае типовой нагрузки в 2.5-3MB/s, всего около 2-3% от полосы пропускания GigE!

        Возможно в данном случае мы упираемся в предел возможности локальных дисков серверов, на смену которым призвана встать система хранения, и сервер имеет большой запас по производительности, если мы обеспечим ему широкую полосу пропускания для данных? Но нет, показатель Disk Read/Write Queue редко когда превышает значение 8-9, что означает относительно слабо нагруженную дисковую подсистему, значит в дисковую производительность сервер практически не упирается.

        Итак, давайте посчитаем. В случае нашей рассмотренной выше небольшой IT-системы из четырех серверов, в случае выбора FC нам необходимы:
        1. по два однопортовых или по одному двухпортовому FC HBA на каждый сервер – 8 однопортовых или 4 двухпортовых (QLogic QLE2462 2port – 700$ * 4 = 2400$)
        2. два FC-коммутатора (недостаточно встроенных FC-портов для подключения всех 6 линков) допустим, пусть это будут массовые и недорогие Brocade 200E – 4000$ * 2 = 8000$.
        3. Лицензия на FC (в зависимости от выбранного массива цена варьируется, например для системы типа FAS2050 это около 1200$ для одноконтроллерной и 2400$ для двухконтроллерной, отказоустойчивой, “кластерной” системы)
        4. ПО поддержки многопутевости (стоит заметить, что в поставке Windows средство обеспечения многопутевости MPIO не поддерживает FC, только iSCSI, и использование MPIO с FC требует установки дополнительного программного модуля, так называемого DSM, обычно предлагаемого поставщиком решения системы хранения, он недорог, но тоже не 0$)
        5. Кабеля FC optical LC-LC для подключения серверов к коммутаторам (8 шт) и коммутаторов к массиву (2 шт) (LC-LC optical 5m – 50$ * 10 = 500$).
        6. затраты на монтаж и настройку (варьируется).
        Кажется ничего не забыл 🙂

        Итого, нетрудно видеть, только на возможность использования протокола Fibre Channel мы потратим по меньшей мере около 12-15 тысяч долларов! При этом, как я показал выше, эти 12 тысяч совершенно не увеличат производительность получившейся системы. Они потрачены исключительно “на понты”, на возможность бросить в разговоре с коллегами “а, мы тут файбер ченэл себе прикупили”. 🙂
        “Хороший понт дороже денег”, не спорю. 😉 Но 12 тысяч это 12 тысяч. Тем более в наше непростое время на дворе.
        Но если бы мы использовали эти, вполне существенные деньги, на что-нибудь действительно дающее реальный эффект, например на пару дополнительных серверов для других задач, премию сисадминам оплату услуг хорошего программиста-оптимизатора баз данных, или, например, в случае системы хранения данных, на дополнительные 10-12 дисков, то за те же деньги мы бы получили (см. ранее про IOPS дисков) систему хранения по меньшей мере на 1800-2500 IOPS быстрее!
        И только за счет отказа от “крутого”, “понтового”, но избыточного, и поэтому совершенно “неполезного” в данном случае Fibre Channel.

        Romx

        http://blog.aboutnetapp.ru/

      • Главная Storages, Новое Fibre Channel, iSCSI
        • Эта мифическая “Скорость интерфейса”

          speedometer “Скорость FC вдвое(вчетверо) быстрее iSCSI”. Так ли это?

        • Главная Storages, Windows, Новое Storages, мониторинг
          • ИОПСы и как их измерить.

            db_status Зачастую камнем преткновения в анализе производительности системы хранения является замер текущей производительности дисковой подсистемы в IOPS. Без таких данных очень сложно, а порой и невозможно спроектировать адекватную систему хранения для имеющихся данных. Ошибка в оценке необходимого уровня производительности может напрямую исчисляться в тысячах долларов, ушедших в «молоко» при создании системы с «перелетом», и не меньших тысячах долларов потраченных на систему, не выполняющую своих задач в случае «недолета».

            Грубой оценкой, но, как правило, достаточной для оценки текущей производительности для базы данных или иной системы, будут показания штатного Performance Monitor (perfmon) из Windows Server.

            В запущенном perfmon к имеющимся по умолчанию счетчикам Pages/sec, Avg.Disk Queue и %Processor следует добавить из группы Physical Disk параметры Disk Reads/sec и Disk Writes/sec для нужного диска (в том случае если исследуемая активность принадлежит одному физическому диску, если же нет – те же параметры из группы Logical Disk). Таким диском может быть, например, диск, содержащий базу данных, почтовую базу или любую другую информацию, которую вы намерены перенести на внешнее хранилище. Обратите внимание, что по умолчанию выбирается общая активность всей дисковой подсистемы (_Total).
            Очевидно, что сумма значений по Disk Writes/sec и Disk Reads/sec будет приблизительно искомой величиной в IOPS.

            Если же мы хотим не просто посмотреть загрузку по IOPS, а провести продолжительный анализ, например для вывявления пиков загрузки и средней величины, то следует воспользоваться так называемыми «журналами счетиков» того же perfmon.
            В Performance Logs and Alerts выбрать «Журналы счетчиков» и создать новый журнал с типом данных, например, csv. Добавить в этот журнал уже знакомые нам объекты Disk Reads/sec и Disk Writes/sec и установить желаемый интервал сбора данных. Следует обратить внимание, что включение счетчиков диска немного, но все же снижает общую производительность дисковой подсистемы дополнительной нагрузкой, это имеет смысл учитывать в интерпретации итоговых значений. Кроме того, слишком малый интервал считывания данных хоть и даст более детальный отчет, но, возможно, излишне нагрузит систему и даст черезмерно объемный файл журнала. Считывания раз в 3-5 секунд будет вполне достаточно. Для больших длительностей замеров имеет смысл выбрать большие интервалы, вплоть до минуты. Позаботьтесь о том, чтобы файл отчета не переполнил отведенное ему место, оставьте систему со включенным журналом регистрации и через искомое время вы получите csv-файл, наполненный значениями загрузки вашей дисковой подсистемы. Путем импорта и обработки в Excel вы сможете извлечь желаемые данные, например, средние и пиковые значения загрузки, время пиковых загрузок.

            Полезными для анализа параметрами будут также значения следующих объектов:
            Disk Bytes Read/sec и Disk Bytes Write/sec – показывают скорость передачи данных с диска. Должны быть близки к величине Disk Reads/sec и Disk Writes/sec помноженных на размер блока файловой системы. Показывают скорость передачи данных с диска. Полезно будет также отметить характер доступа, соотношение операций чтения к записи.
            Avg.Disk Queue – показывает величину «очереди запросов» к диску. Значение длительно удерживающееся заметно выше 1,5..2*количество шпинделей дисков показывает перегруженную дисковую подсистему или дисковый контроллер, величина показывает количество запросов стоящих в очередь к диску и ожидающих его освобождения после выполнения предшествующих запросов.
            %Processor – постоянная загрузка выше 60%-80% показывает слабость имеющегося процессора для выполняемой задачи, либо наличие какой-то «паразитной» загрузки сервера посторонними задачами.
            Pages/sec – показывает количество считываний и записей «страниц» в памяти для того, чтобы добраться до нужной для проводящийся в данный момент операции. Резко отличающиеся величины при работе указывают на недостаток оперативной памяти, приводящей к постоянным операциям «paging»-а, переключения страниц, снижающего быстродействия. Величина должна быть близка к нулю в нормальном, непиковом состоянии.

            Большое количество специфичных для себя счетчиков добавляет в perfmon установка MS SQL и MS Exchange. Среди них можно обнаружить объекты, измерение которых может помочь детализировать данные по отдельным базам данных или по определенным операциям.
            Полное описание всех средств Performance Monitor в Windows Server далеко выходит за рамки этого обзора поэтому ограничимся вышеприведенным.
            Интересующихся можно отослать к следующим статьям:

            «Семь наиболее полезных счетчиков эффективности» (SQL.ru)
            «Счётчики производительности SQL Server и Windows»

            Romx

            http://blog.aboutnetapp.ru/

          • Главная Storages, Новое ИТ инфраструктура, мысли
            • Кризис – хорошее время искать оптимальные решения

              money Я уже поднимал в этом блоге тему оптимальных решений той или иной задачи. К сожалению, в нашей стране так до сих пор и остались пустыми словами понятия “стоимости владения”, которым так много внимания уделяется во всем мире.

              Ну это наша традиционная болезнь. Чтобы уменьшить фотографию с пьянки нет лучше средства чем Adobe Photoshop CS3, а eсли ставить “венду” – то только Datacenter Edition. “Красть – так миллион, … так королеву” 🙂

              Компания, на которую сваливаются нежданные IT-бюджеты ведет себя как “новый русский” из анекдотов в магазине: “Принесите мне все САМОЕ дорогое! Плачу наличными!”. И если бы в самом деле платил 🙂 На деле понты не дают возможности купить не САМОЕ дорогое, а на дорогое денег… как бы… не особо-то. 🙂 Особенно сейчас.

              Однако предложение: “Ну зачем вам вот это вот, оно для вас сейчас совершенно ни к чему, вы его просто не сможете использовать в полной мере, а стоит оно тут ого-го, возьмите вот так вот, и все будет работать точно также” воспринимают не менее чем как оскорбление. “Как! Мы биг энтерпрайз (ну по крайней мере хотим ими быть), а вы нам какой-то едва ли не entry level подсовываете!”

              Простой пример из жизни. У клиента сравнительно небольшая IT-система, в которой два сервера SUN, файлы (и в перспективе базу Oracle) которых надо бэкапить. Есть небольшая ленточная библиотечка для этого, будет еще какой-то дисковый массив. В общем все достаточно экономично.

              Предполагается использовать для этого Symantec NetBackup.

              Ну тут, в принципе, все просто: один NBU Server, два NBU Client for UNIX и лицензия на Tape Library, 1 Drive.

              Затык один: клиент хочет “чтобы бэкап шел по SAN”, чтоб все “как у больших”.

              Ну, если “как у больших”, то тогда нужны уже версии Enterprise для сервера и клиентов, только в них есть SAN Backup и SAN Client.

              А это совсем другие деньги, тоже как для “больших”.

              Итого, в рекомендованных ценах от Symantec – более 39 тысяч долларов для всего двух серверов!

              И каждый следующий подключенный сервер обойдется как минимум в 15 тысяч!

              И это только за нашу прихоть “бэкапить по SAN” и больше ни за что (больше никакие другие функции Enterprise Client/Server использовать не планируется).

              Но если мы не боимся, что нас “пацаны засмеют”, и воспользуемся стандартным бэкапом по сети (а ведь для бэкапа по сети, если уж мы ни в какую не хотим бэкапный трафик пустить в общую LAN, мы запросто можем поставить выделенный гигабитный сетевой адаптер), то нам будет достаточно версий Standard, и, для того же самого, всего около 14 тысячплюс 1700$ за каждого дополнительного клиента).

              А если мы еще чуть внимательнее отнесемся к экономии денег, и тщательнее посмотрим на прайс Симантека то обнаружим там такую чудесную вещь, как NetBackup Starter Kit, в который входит “NBU Server for UNIX Tier 2 + Tape Library License + 5 NBU Clients”, то есть все то что нам надо, плюс еще три клиента на будущее, в запас, и за все про все – 6000 долларов!

              Итак, за каприз клиента “хотим как у взрослых” он заплатит, причем без малейшей реальной эффективности и выгоды для своей IT-функциональности, в шесть с половиной раз больше!

              Это ли не красноречивый пример IT-расточительности?

              Romx

              http://blog.aboutnetapp.ru/

            • Главная Storages, Новое NetApp, WAFL, файловая система
              • Почему я считаю, что WAFL это не файловая система?

                pie-chart_view Костадис Руссос (http://blogs.netapp.com/extensible_netapp/2008/10/why-wafl-is-not.html)
                Мой перевод оригинального авторского текста.

              • Главная Storages, Новое Storages, мысли
                • О сбалансированности

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

                  «Перелет» – система «навырост»

                  Достаточно распространенный случай несбалансированной системы это покупка системы «навырост», под дальнюю перспективу, неоправданную на сегодняшний день, либо с переоценкой потребностей. Немалую роль в этом играют и сами системные интеграторы, которые всегда рады «исполнить любой каприз заказчика за его деньги», и, разумеется, поощряющие его на такие дорогостоящие капризы. Чаще всего они пользуются как неадекватной оценкой потребностей клиента (например, отсутствием или неверно выполненным анализом необходимой производительности информационной системы, частью которой становится система хранения, завышением требований), либо путаницей, зачастую преднамеренной, созданной многочисленными маркетинговыми обещаниями.

                  «Мы не хотим покупать систему с 2GB FC портами, ведь уже есть 4GB порты, а они вдвое быстрее!».
                  «Нам нужна система хранения с самыми быстрыми дисками, на 15K. Ведь когда у нас стояли в сервере два диска SCSI на 10K, все было очень медленно».
                  «Мы хотим библиотеку на дисках BluRay, потому что это самая новейшая технология. Библиотеки на магнитных лентах давно устарели!»

                  В защиту такого поведения системных интеграторов следует сказать, что зачастую процесс апгрейда имеющейся системы хранения для оборудования большинства вендоров-создателей систем хранения зачастую сопряжен с серьезными временными и денежными затратами (приятным исключением являются системы Network Appliance). Затраты настолько велики, что зачастую выгоднее становится, при малейшем подозрении на перспективы значительного роста (и зачастую невозможности провести адекватный «сайзинг»), потратить сегодня больше, с тем чтобы отодвинуть время необходимости смены системы хранения как можно дальше в будущее, а в идеале передать этот хлопотный и мучительный процесс следующему IT-менеджеру 😉

                  «Недолет» – всюду жмет

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

                  «Давайте купим самую дешевую систему, ведь главное, чтобы на нее поместилась наша база данных!»
                  «Может быть просто купить 6 дисков SATA для нашего сервера, и этого будет достаточно?»
                  «Мне выделили 3 тысячи долларов на покупку системы хранения, надо купить что-нибудь крутое за эти деньги. Например терабайта на два-три».

                  Результатом может быть лишь разочарование.
                  Впрочем даже не выполняющая свои задачи система хранения увеличивает общую капитализацию компании, и бонусы как продавца, так и покупателя, что в ряде случаев также может оказаться полезным 😉

                  Несбалансированная система – «перекосы»

                  Обычно это частный случай рассмотренного выше, сочетание первого и второго, когда в системе что-то одно «жмет», а что-то другое «навырост».

                  4GB FC ports и диски SATA
                  Диски 15Krpm на системе для резервного копирования данных.
                  Восьмипроцессорный сервер под 1С:Предприятием 7.7

                  При несбалансированности решения вполне можно потратить бездну денег и получить 5% прирост производительности. Хороший пример – недорогая система хранения начального уровня, наполненная дисками 15K. По сравнению с дисками 10K цена вырастает минимум на треть, однако вовсе не факт, что на недорогой системе хранения производительность вырастет в полтора раза, как это могло бы быть на более мощной системе с большим кэшем и более мощным процессоро
                  м обработки. Просто возникает эффект «бутылочного горлышка»: как ни дави, сколько ни трать денег, все равно больше, чем просочится через самое узкое место, из системы не выжать. Происходит эффект мотора от Феррари на Жигулях. Много дыму, рева, расхода высококачественного бензина, однако реальная скорость передвижения практически не увеличилась.

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

                  «Недодумали» или «переоценили»

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

                  Пример из жизни
                  Крупный химический завод хочет создать отказоустойчивую систему управления производством, использующую базу данных Oracle. Для этого создается кластер на базе Veritas Cluster Server из двух серверов SUN, приобретается common storage EMC CLARiiON CX, к которому по FC подключаются два сервера SUN Fire V. Казалось бы, все хорошо: в случае выхода из строя одного из серверов, с помощью служб VCS задача системы управления производством, представляющая собой БД Oracle и написанные вокруг нее приложения, рестартует на резервном сервере. Однако в какой-то момент из спецификации «в целях экономии IT-бюджета» вычеркивается Veritas Storage Foundation с журналируемой файловой системой VxFS для Solaris. И все устанавливается на обычный UFS.

                  И теперь в случае выхода из строя первичного сервера, резервный запускается, монтирует на себя common storage на EMC CLARiiON, и… запускает fschk.
                  На 20 минут.

                  «“Немного недодумали” чаще всего означает, что не думали вообще».

                  Romx

                  http://blog.aboutnetapp.ru/

                • Главная Storages, Новое NetApp, Storages
                  • NetApp System Manager

                    Netapp-logo Исторически первым интерфейсом администрирования систем хранения NetApp была командная строка в консоли администратора, доступная по телнету или ssh для любой системы NetApp.
                    Так как, исторически, главной “целевой аудиторией” для первых систем хранения NetApp были системные администраторы UNIX, было решено сделать консоль администрирования настолько похожей на стандартную UNIX-консоль, насколько это возможно.
                    Именно потому, что консоль NetApp настолько “юниксподобна”, это год за годом порождает слухи в “хитро спрятанном линуксе инсайд” хотя внутри NetApp и совершенно не UNIX, или по крайней мере нечто, совсем отличное от известных большинству UNIX-систем. Давным-давно я уже писал, что именно находится внутри, интересующиеся могут сходить в тот пост.

                    С расширением “аудитории” NetApp возникла потребность в создании чего-то более GUI-образного и “интуитивно-понятного”, и в 1996 году, 13 лет назад, появился веб-интерфейс FilerView, на тот момент один из первых такого рода на рынке систем хранения.

                    filerview

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

                    Повторюсь, для 96 года это был прорыв. Однако с той поры прошло уже, страшно подумать, 13 лет, выросло уже, по сути, новое поколение “сисадминов”. Веб-технологии развивались стремительными шагами, и интерфейс FilerView стал выглядеть, деликатно выражаясь, несколько архаично. Да он по прежнему прост и функционален, по прежнему делает все, что необходимо, но уже совсем не “радует глаз”.
                    Зачастую это даже стало вызывать определенное отторжение у новичков. Встречают в мире по прежнему по одежке.

                    В недрах NetApp довольно давно велись работы в этом направлении, так, standalone GUI под названием StorVault Manager получило семейство StorVault (S-Series), выходили специальные “мастера” начальной устрановки систем FAS под Windows (QuickSetup Wizard и FAS Easy Start Wizard), а также продукты Protection/Provisioning Manager, “гуизирующие” определенные фрагменты общего процесса.

                    2

                    3

                    4

                    И вот, наконец, все вместе, в новом продукте для управления вашими системами FAS: NetApp System Manager.

                    Важно понимать, что, также как появление FilerView в 1996 году не убило командную строку, так и появление System Manager не означает конец жизни FilerView или командной строки. Вы можете по прежнему пользоваться тем, что вам более удобно, и их разработка будет продолжена. Но появились и будут появляться впредь новые инструменты. Давайте посмотрим что ж нам приготовили.

                    Скачивается дистрибутив NetApp System Manager, размером 4 MB с вебсайта NOW, там же, где и все остальное ПО NetApp, и доступен без оплат и лицензий.
                    Он представляет собой надстройку для стандартной Microsoft Management Console (MMC).

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

                    5

                    Затем нам предлагают осуществить подключение, которое мы выберем по SSL.

                    6

                    Будет спрошено имя администратора системы храненя, и – все. Система подключена.

                    7

                    Выберем ее, и увидим вот такую красоту:

                    8

                    Это стандартный дашборд, показывающий определенный набор “оперативных данных”.
                    Выберем слева в дереве объектов нас интересующее:

                    Например вывод syslog системы:

                    9

                    Или настройку CIFS:

                    10

                    Настройки сетевых интерфейсов:

                    11

                    Или создание и настройку LUN-ов:

                    12

                    В также настройки томов и состояние дисков:

                    13

                    14

                    В целом система мне показалась безусловным мастхэвом, и если вы администрируете системы NetApp сидя под Windows (SysMan это MMC-надстройка), то имеет смысл посмотреть System Manager повнимательнее.

                    Romx

                    http://blog.aboutnetapp.ru/