• Тестируем внешние HDD через различные подключения.

    logo

    Прочитав статью Михаила Комарова о виртуализации и активно ее комментировав, я задался вопросом: “Какой способ подключения внешнего диска все-таки быстрее? ”

  • Главная Virtualization, Без рубрики HDD, iSCSI, Storages, VMware, виртуализация, СХД
    • Дешевое разделяемое хранилище для ESX

      Для полноценной работы почти всего функционала ESX, кроме непосредственного запуска виртуальных машин, требуется shared storage, разделяемое хранилище. Для HA и VMotion, и того, что с ними связано – DRS, Fault Tolerance.

      Но что делать если нет денег на HP EVA, NetApp и даже на Starwind iSCSI? Спасут старые добрые пингвины и старенький, уже слабый, но все еще исправно работающий сервер.

      Итак, берем сервер, очень желательно с аппаратным RAID и обязательно с гигабитной сетью, и набиваем его дисками. Программная часть: CentOS, iSCSI Enterprise Target и/или стандартный NFS сервер, идущий в комплекте с CentOS. Я взял дистрибутив, бывший под рукой, CentOS 5.3 32bit.

    • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Storages, Конкурс
      • Exchange 2010 и SIS

        Small Single Storage Unit В Exchange Server 2010 больше нет системы Единого экземпляра хранения объектов – SIS, Single Instance Storage.

      • Главная Storages, Новое Storages
        • О “дешевизне” SATA-дисков

          sata-power-latching-cable Ранее, в посте про надежность RAID-5 я уже писал про такой аспект дисков SATA, как надежность и величину UER (Unrecoverable Error Rate, иногда также называется UBE – Unrecoverable Bit Error).
          Величина эта почти на порядок (в 10 раз) хуже, чем для дисков SAS/FC, причем причина тут конструктивная, а не просто в интерфейсе.
          Однако, для небольших систем “начинающих”, в первую очередь роль играет цена.

          Жесткий диск (и система хранения) характеризуется, в общем случае, двумя параметрами: емкостью (измеряется в Мегабайтах/Гигабайтах (MB/GB)), и быстродействием (измеряется в IOPS – Input-Output Operations per Second – Операций ввода-вывода в секунду ). И если емкости дисков непрерывно растут вот уже несколько лет, то показатели по IOPS замерли уже довольно давно.
          Принято считать, что диск SATA дает 80-100 IOPS, диски SAS/FC – 140-160 для 10KRPM, 180-200 – 15KRPM.

          Стоимость за мегабайт для дисков SATA весьма низка, на сегодня она составляет 0,17$/MB для диска SATA 1TB, однако около 0.83$/MB для диска SAS 300GB. (я оперирую ценами, взятыми из price.ru: SATA WD RE3 1TB 7200 – 170$, SAS Hitachi 300GB 15K – 250$)

          Иная картина будет, если мы посчитаем стоимость IOPS-ов. Диск SATA при этом будет стоить 2,1$ за IOPS, а 15K SAS – 1.38$/IOPS

          Допустим, перед нами стоит задача создать сторадж на 3 TB, при этом быстродействие его должно быть не хуже 3000 IOPS.

          Рассмотрим два варианта:
          Если мы рассматриваем только емкость, то будет все просто:
          SATA 1TB нужно три штуки, при цене за диск в 170$ общая сумма хранилища заданного размера, без учета RAID будет 510$
          Дисков SAS на 15KRPM емкостью 300GB будет нужно 10 штук, при цене за диск 250$ такая емкость будет стоить 2500$

          Казалось бы вывод очевиден, SATA дешевле, причем раз в пять.
          Но мы пока не учли второе требование, про 3000 IOPS.

          Для быстродействия системы емкостью 3TB в 3000 IOPS, из расчета в 80 IOPS с каждого диска SATA, нам нужно распараллелить ввод-вывод не менее чем на 38 дисков. 38 дисков SATA, это будет стоить уже 6460$.
          Однако для дисков SAS те же 3000 IOPS достижимы на всего 17 дисках, что стоит 4250$

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

          Этот момент часто не учитывают люди, планирующие использование SATA на задачах primary storage.

          Если перед вами стоит задача не просто создать емкость хранения, без учета показателей по быстродействию, что, вообще говоря имеет только одно применение – хранилище архивных и резервных копий, а систему хранения, обеспечивающую приемлемую скорость работы приложения его использующего, то вам следует забыть про гигабайты, и ориентироваться, в первую очередь, на производительность дисков, на IOPS. Необходимый объем вы получите “автоматически”.
          Сегодня, во многих случаях, при планировании системы хранения, производительность есть ее “первичное”, ключевое свойство .
          Или, иначе говоря: “GB are free, IOPS cost you money” – “Гигабайты бесплатно, вы платите только за доставку ИОПСы”

          http://blog.aboutnetapp.ru

        • Главная 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, 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, Новое 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/