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


     

  • Главная Exchange/UC, Storages AntiSmap, Exchange 2010
    • Динамические белые списки

      simplicity Как-то давно я предложил одну идею, направленную на борьбу со Spam’ом. Я рассказал о ней Паше Нагаеву, Олегу Крылову и другим ребятам, занимающимся системами обмена сообщений. Они выслушали меня, подискутировали, согласились, что идея имеет рационально зерно и… И на этом, можно сказать, всё и остановилось 🙂 .
      Но меня, всё время, никак не оставляло то, что идея не имеет практической реализации. На TechEd 2008 в Барселоне я познакомился (а точнее меня познакомил Паша Нагаев) с Александром Николаевым. Александр уже давно живёт в Америке и является Product Manager’ом ForeFront’а. Так вот, как это обычно и бывает, я хотел связаться с Александром, дабы обсудить с ним мою идею, но всё время откладывал это в долгий ящик. Но случилось неожиданное – Александр посетил наши IT-посиделки и это дало мне тот самый толчок, которого мне так не хватало! Мало того – в кои-то веки я лично пишу об этом в блоге, хоть и не своём 🙂 .
      Ну что ж, достаточно интриги и буду ближе к делу. Моя идея состоит в формировании белых списков, но вся прелесть в том, что эти списки динамические! В общих чертах, как я предлагаю этого достичь:

    • Главная 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
              • Приводит ли большая нагрузка к увеличению вероятности выхода дисков из строя?

                windowslivewriterfreeonlinebackupmozyonover-ceb7hard-drive-diag2 Сегодня мы продолжаем разбирать результаты опубликованной специалистами Google научной работы, в которой анализируются причины отказов 100.000 жестких дисков в датацентрах Google на протяжении пяти лет.

                Мы считаем само собой разумеющимся тот факт, что бо’льшая нагрузка на диски вызывает их более ранний выход из строя. Так ли это? Данные Google показывают, что это не так. Более того, результаты сами по себе неожиданны.

              • Главная Storages, Новое MTBF, СХД
                • О надежности жестких дисков: MTBF – что это?

                  Hard drive Давно, еще в 2007 году, я публиковал в одном из первых постов этого блога, ссылку на исследование группы инженеров Google, которое они обнародовали на одной из конференций исследовательской группы USENIX (USENIX File and Storage Technologies, 2007 – FAST07). На сегодняшний день это самое крупное такое исследование по количеству наблюдавшихся “в естественной среде” жестких дисков. Несмотря на то, что документ этот широко доступен, уверен, что мало кто сел и внимательно прочитал его целиком, а потом еще и подумал над содержимым. Потому что результаты там, подчас, предстают самые неожиданные.

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

                    • Failover cluster на Windows Server 2008 R2. Коротко о главном

                      image

                      Успех бизнеса все чаще зависит от бизнес-приложений, выполняемых на серверах. Доступность сервера становится приоритетной задачей. Работа в режиме “24x7” важна в тех областях, в которых системы должны быть в постоянно доступны, чтобы не потерять своих клиентов. Владельцы больших почтовых систем и баз данных могут потерять тысячи долларов или даже лишиться своего бизнеса, если произойдет отказ системы.