Главная 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.

  • Главная Storages, Новое HDD, NetApp, СХД, файловая система
    • Еще о фрагментации

      126_9 Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (random) по характеру доступ.

      Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.

    • Главная Storages, Новое HDD, NetApp, СХД
      • Влияет ли фрагментация данных на скорость random-доступа?

        Одной из вечных тем FUD-а конкурентов NetApp является “проблема” с фрагментаций данных в WAFL.
        Оставим сейчас в стороне вопрос, насколько фрагментация действительно проявляется в практической жизни (я на эту тему уже писал ранее). Рассмотрим только вопрос того, насколько такой эффект вообще имеет место быть в теории.

        Алекс Макдональд, инженер NetApp, в своем блоге привел любопытную модель, оценивающую влияние фрагментации на эффективность, в случае случайного (random) по характеру доступа.

        Он заполнил таблицу из ста строк сотней случайных чисел, взятых с random.org, в первом столбце, которые изображают фрагментированные данные, затем второй столбец также случайными числами, изображающими то, какой блок программа запросила, в случае рандомного доступа к данным. И наконец он сравнил суммарное расстояние “seek” в случае считывания запрошенных данных (второй столбец) из максимально фрагментированного массива (первый столбец) и упорядоченного (то есть просто от 1 до 100).

        Random Placement

        Random Requested Block

        Matching Block (Random Placement)

        Seek Distance (Random Placement)

        Seek Distance (Sequential Placement)

        67

        80

        22

        0

        0

        19

        37

        58

        36

        43

        75

        18

        61

        3

        19

        23

        26

        53

        8

        8

        85

        57

        63

        10

        31

        59

        100

        14

        49

        43

        14

        59

        6

        8

        41

        SUM

          

          

        3269

        3322

        С точки зрения “здравого смысла” мы бы ожидали, что фрагментированный столбец даст значительно (или хотя бы заметно) большую величину “seek”, по сравнению с упорядоченным, однако этого не произошло! Более того, столбец со случайно заполненными данными, из которого столь же случайно “запрашиваются” числа имел даже чуть меньший “seek” чем полностью упорядоченный! (Впрочем, ясно видно, что на достаточно большом интервале эти числа будут стремиться сравняться, так что можно просто принять их равными).

        Несколько неожиданный для “здравого смысла” результат, однако, поразмыслив, нельзя не признать его правильным. “Случайное” помноженное на “случайное”  не дает “случайное в квадрате”. 🙂

        Отсюда немного парадоксальный вывод: В случае случайного (random) по характеру доступа к данным, а именно такой тип нагрузки обычно и принято тестировать в первую очередь, так как он наилучшим образом соответствует работе современных многозадачных серверных систем и баз данных OLTP, фрагментация (случайность их размещения) данных на диске практически не увеличивает количество “вредоносного” seek distance по сравнению со случайным чтением упорядоченных данных, и не ухудшает характеристики производительности!

        romx

        http://blog.aboutnetapp.ru/


         

      • Главная Storages, Новое HDD, RAID, СХД
        • Надежность RAID 5, качество SATA, и Дед Мороз.

          dead-moreau Сокращенный перевод поста Chris Lionetti, Reference Architect – Microsoft Solutions Engineering

          Этот пост рассматривает проблему Unrecoverable Error Rate (UER), «Уровня невосстановимых ошибок» на жестких дисках.

        • Главная Storages, Новое HDD, RAID, СХД
          • RAID-5 – must die!

            how_many_must_die-705175 Да уже и не must, а почти что almost.

            Еще несколько слов аргументации за переход к RAID-6, тем, у кого он не тормозит, не будем показыват пальцем, но: “Есть такие вендоры!” ;).
            Да, согласен, RAID-10 тоже вполне может пережить отказ двух дисков, если вам повезет, что это произойдет в разных половинах “зеркала”. Но только в этом случае.

            • Приводит ли повышенная температура среды к частому выходу дисков из строя?

              e996eaea2ce43f03493b264b71f9f1dc Продолжим внимательное чтение отчета специалистов Google – Failure Trends in a Large Disk Drive Population (pdf 242 KB) опубликованный на конференции FAST07, и содержащий статистический анализ отказов "популяции" 100000 дисков consumer-серий примерно за пять лет срока их службы.

              Это четвертая, заключительная статья, предыдущие:
              Насколько можно доверять величине MTBF?
              Приводит ли большая нагрузка к повышению вероятности отказа?
              Насколько полезен и стоит доверия SMART?

              Мы обнаружили, что основной параметр отказоустойчивости, приводимый производителями, MTBF – Mean Time Before Failure, бесполезен, и не коррелирует вообще с реальными показателями отказов. Мы узнали, что SMART бесполезен едва ли не более, чем полезен, и что значительная часть отказов происходит без корреляции с показаниями SMART. Наконец, мы с неожиданностью поняли, что общепринятая "аксиома" о том, что высокая нагрузка повышает вероятность выхода из строя дисков – как правило, неверна.

              Но главный сюрприз у нас еще впереди.

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

              image-thumb1

              На приведенном графике в виде столбиков приведено количество дисков, имеющих соответствующую температуру (с шагом в 1 градус, можно рассматривать как "температуру перед сбоем", так как полученная корреляция просматривается в различных вариантах измерений). Кривая с точками и T-образными символами показывает полученный уровень AFR с зарегистрированным разбросом показателей.

              Как мы видим, повышение рабочей температуры до 40 градусов включительно приводит к снижению уровня отказов, но даже дальнейшее повышение ее до 50 и более поднимает его незначительно (отказы при температуре 50 градусов примерно соответствуют уровню отказов при температуре 30 градусов). Напротив, дальнейшее понижение температуры до 20 и менее, ведет к почти десятикратному росту отказов, относительно оптимальной температуры в 35-40 градусов!
              (Большой статистический разброс результатов, показанный T-образными отметками, вызван снижением общего количества “испытуемых” дисков в предельных температурных областях)

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

              image-thumb2

              "Переохлаждение" для дисков, то есть работа при температурах ниже 30 градусов (имеется ввиду, конечно же, температура самого диска как устройства, как ее определяет встроенный температурный датчик SMART), для устройств сроком до двух лет эксплуатации включительно, в два-три раза повышает величину отказов, даже по сравнению с ранее считавшимися "перегревом" температурами выше 45! Только для дисков старше 3 лет перегрев становится причиной повышенного выхода из строя. Снова видно, что для дисков, переживших 3 года, вероятность отказа сильно падает. Видимо где-то в районе трех лет проходит какая-то довольно заметная граница работоспособности.

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

              Результат, по-видимому, еще стоит осмысления и оценки.

              romx

              http://blog.aboutnetapp.ru/

            • Главная Storages, Новое Google, HDD, СХД
              • S.M.A.R.T – Self-Monitoring, Analysis and Reporting Tool. Насколько он полезен?

                93smart_eco-speedster_01 Являющиеся частью стандарта ATA, средства мониторинга и предсказания ошибок, носящие название S.M.A.R.T – Self-Monitoring, Analysis and Reporting Tool присутствуют в контроллерах всех дисков ATA (как PATA, так и SATA) с 90-х годов. По мысли разработчиков этих средств, они должны предотвратить неожиданные выходы из строя, так как SMART оценивает ряд критичных параметров диска, и пытается предсказать вероятность таких сбоев, а также ожидаемое время до сбоя.

                Группа исследователей Google на протяжении 9 месяцев анализировала данные S.M.A.R.T. в 100 тысячах дисков, расположенных в его датацентрах, выявляя взаимосвязи между отказами дисков, и показаниями этой службы. Было выявлено несколько критичных параметров, события которых чаще других вызывали впоследствии отказы таких дисков.

              • Главная Storages, Новое Google, HDD