Archive for октября 2009

10Gb Ethernet в NetApp

Любопытные сведения найдены в блоге одного из сотрудников NetApp:

  • NetApp была первой компанией из производителей систем хранения, представившей поддержку 10Gb Ethernet в своей продукции, еще в 2006 году.
  • Количество отгружаемых компанией “портов” 10Gb Ethernet за год, с июня 2008 по июнь 2009 выросло на 150%
  • В настоящий момент более 11% всех портов на поставляемых в системы хранения картах расширения Ehernet это порты 10Gb Ethernet.

Тебибайты

Нет времени писать на этой неделе большие трактаты. Поэтому отделаюсь маленькими заметками.

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

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

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

Неожиданно выясняется, что разница между “Гибибайтом” и “Гигабайтом” превышает 7 процентов, а между “Тебибайтом” и “Терабайтом” – почти 10%!
Это уже более чем существенно!

               decimal bytes                    binary bytes
TB 1000000000000 1099511627776
  9,95%  
GB 1000000000 1073741824
  7,37%  
MB 1000000 1048576
  4,86%  
KB 1000 1024
  2,40%  

Игнорировать 10-процентный эффект разницы уже нельзя. Так, например, если вы рассчитываете на 4-гигабитном канале передачи данных, скорость которого рассчитана из “двоичных байт” передавать хранимый на дисках объем данных, исчисленный из “десятичных байт”, вы получите “результат” отличающийся на более чем 7%, на каждом переданном гигабайте, просто по причине набегания этой ошибки.

Поиграть с величинами и понять масштабы проблемы можно, например, в онлайн-калькуляторе.

Новые Best Practices на русском языке

4 миллиарда фотографий

Один из клиентов NetApp - фотохостинг Flickr, принадлежащий ныне Yahoo, взял недавно новую высоту.
Четыре миллиарда закачанных пользовательских фотографий, при этом следует помнить, что при выбранной Flickr архитектуре хранения, каждая фотография хранится в виде 4-5 файлов разного разрешения, то есть суммарное количество файлов хранения еще в 4-5 раз больше.

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

Однако 4 миллиарда это не рекорд. Так, другой клиент NetApp, компания Facebook, хранит свыше 15 миллиардов фотографий (на апрель этого года).

О вероятностях сбоев в серверной DRAM

Не совсем по тематике блога о системах хранения, но тем не менее весьма любопытный документ был недавно опубликован.
Те же авторы, Eduardo Pinheiro и Wolf-Dietrich Weber, их работу Failure trends in large disk drive population мы разбирали недавно, плюс Bianca Schroeder из Carnegie Mellon University, ныне University of Toronto, за ее отчет я также возьмусь в скором времени, опубликовали анализ сбоев в DRAM серверов Google, наблюдаемых в течении 2,5 лет: “DRAM Errors in the Wild: A Large-Scale Field Study”.

Результаты довольно пугающи. В среднем на каждый модуль DRAM приходилось по 3751 ошибке в год. Хороший аргумент за однозначный выбор ECC DRAM в серверах.
Из неожиданных результатов, как и в случае жестких дисков, выяснилось, что высокая температура также слабо коррелирует с вероятностью появления ошибок в DRAM.
Подробный 12-страничный документ можно взять по ссылке: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Порты FC на системах NetApp и расширение их количества

UPDATE: ВНИМАНИЕ! Данный текст устарел!

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

Контроллеры систем хранения NetApp современных серий приходят с определенным числом встроенных портов FC (2 на контроллер на FAS2000, по 4 на FAS3×00, по 8 на FAS6000). Для кластерных (двухконтроллерных) систем количество удваивается. Кроме этого все модели (за исключением FAS2020 и 2040) имеют слоты расширения, куда можно установить те или иные интерфейсные карты. Однако существует ряд правил, определяющих возможные конфигурации.

Для начала о терминах.
Порты FC могут находиться в следующих состояниях:
Initiator - сторона "сервера". То, на чем работает использующее дисковый ресурс приложение, то, что “инициирует” процесс чтения или записи данных.
Target - сторона "диска". То, на чем создается и раздается дисковый ресурс, то что является “целью” для процессов чтения и записи данных, хранит их, и отвечает на запросы инициатора процесса.

В случае NetApp:
Target – a fibre channel port used for connecting LUNs to hosts or servers.
Initiator – a fibre channel port used for connecting disk shelves to the storage controller or to VTL

 


1. Можно ли смешивать в одном контролере карты расширения FC target(для подключения серверов) и карты расширения FC initiator, например для подключения ленточной библиотеки или дисков?

ДА

Карты расширения могут быть как target (в которые включаются хосты), так и initiator (в которые включаются дисковые полки). Обязательно проверьте по Configuration Guide, совместимость желаемых карт с вашей системой, допустимое количество устанавливаемых карт расширения определенного типа, и разрешенные для установки соответствующих типов карт слоты расширения.


2. Можно ли использовать FC-карты расширения И порты FC на контроллере для подключения к ним дисковых полок (и те и другие в режиме Initiator)?

ДА

Порты в режиме initiator могут работать одновременно, как на платах расширения, так и встроенные в контроллер.


3. Можно ли использовать FC-карты расширения как target (для подключения серверов) И одновременно использовать как target какие-то из портов FC на контроллере?

НЕТ

Использование как target-ов портов на картах расширения запрещает использование как target-ов встроенных портов контроллера. Их можно при этом продолжать использовать только как initiator-ы( подключать к ним дисковые полки).


4. Можно ли сконфигурировать часть портов многопортовой карты расширения FC как target (для подключения к ним серверов), а часть этих портов - как initiator (для подключения к ним дисковых полок)?

НЕТ

Каждая физическая карта расширения может находиться либо в режиме target, либо в режиме initiator только целиком.


5. Можно ли подключиться к части портов FC на карте расширения на скорости 2Gb/s, а к другим - на 4Gb/s?

НЕТ

Каждая многопортовая карта расширения может находиться в определенном режиме скорости FC только целиком.


6. Можно ли подключиться к портам одной карты расширения на скорости 2Gb/s, а к портам другой карты расширения - на 4Gb/s?

ДА

Разные физические карты расширения могут находиться в разных режимах скорости FC.


7. Могу ли я использовать часть встроенных FC-портов контролера как target (для подключения серверов), а другую часть - как initiator (подключить к ним дисковые полки)?

ДА, но:
Если в системе нет карт расширения FC-target.

Встроенные порты FC на контроллере могут произвольно находиться как в target-, так и в initiator-mode, по выбору админа. Однако установка платы расширения в target-mode запрещает использование target-mode на всех встроенных портах целиком.


8. Могу ли я использовать часть встроенных FC-портов контролера как target (для подключения серверов), а другую часть - как initiator (подключить к ним дисковые полки) даже если оба этих порта работают на одном FC-чипе (ASIC)?

ДА, но:
Если в системе нет карт расширения FC-target.

Встроенные порты 0a и 0b (а также 0c и 0d, 0e/0f, 0g/0h) обслуживаются одним ASIC-чипом на пару этих портов. Совмещать режимы для встроенных на контроллере портов можно произвольно.


Пример:
У нас есть одноконтроллерная система FAS3140, с 4 встроенными в контроллер портами FC 4Gb.
1. Мы хотим подключить к контроллеру дисковую полку.
2. Мы хотим получить на системе 4 порта для подключения к ним серверов.

Неправильное решение:
Купить 2-портовую карту в слот расширения, на два встроенных порта подключить полку, на два - сервера, и еще два сервера на два порта на карте расширения.
Карта расширения в target mode запрещает target mode на встроенных портах.

Правильное решение:
Купить 4-портовую карту, установить ее в target mode, а в два встроенных в контроллер порта включить дисковую полку. Останутся свободными еще два встроенных порта в режиме initiator, для подключения дисковых полок.


Пример:
У нас есть одноконтроллерная система FAS3140, с 4 встроенными в контроллер портами FC 4Gb/s.
1. Мы хотим подключить к контроллеру одну полку типа DS14MK4 (с дисками на 4Gb/s), и старую полку DS14MK2 (с дисками на 2Gb/s).
2. Мы хотим подключить 2 серверных хоста.

Неправильное решение:
Купить 4-портовую карту расширения, поставить ее в initiator mode, и включить в пару портов полку DS14MK4, а в пару - DS14MK2. Во встроенные в контроллер порты включить сервера.
Совмещать разные скорости FC на одной карте нельзя (но можно на встроенных портах)

Правильное решение:
Купить 2-портовую карту расширения, поставить ее в target mode, и включить в нее серверные хосты. Встроенные порты перевести в initiator mode, и включить в 2 из них DS14MK2, а в два - DS14MK4.

Дедупликация и производительность работы

Часто приходится отвечать на вопрос: "Насколько использование дедупликации снижает производительность системы хранения NetApp?"

Официальное мнение, подтверждаемое отчетами пользователей: "Снижение производительности либо практически не заметно, либо находится в пределах 5-7% , в зависимости от нагрузки и характера доступа к системе"

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

Простой пример. Вы используете систему хранения FAS3140, с размером кэш-памяти на контроллере в 8GB (на два контроллера - 16GB, по 8 на каждом), для хранения множества однотипных виртуальных машин.
Не секрет, что системные разделы виртуальных машин Windows, в том случае если вы, как оно обычно и бывает, используете одну и ту же версию OS и сервиспаков, отличаются между собой очень незначительно. Допустим, что 90% всего содержимого OS, установленного на раздел виртуального диска, размером 4GB, идентичны для всех 20 имеющихся у вас виртуальных машин (данные у них, разумеется, различные, но мы говорим сейчас только о системных разделах).
Легко видеть, что, в этом случае, после проведения дедупликации, на разделе, ранее занятом на 4GB*20=80GB высвободится 90%  места, и все данные поместятся в 11,6GB (4GB + (0,4GB*19)).

Такой результат означает, что практически все содержимое наших системных разделов виртуальных машин поместится в кэш системы хранения (16GB), что в разы поднимет ее результирующее быстродействие после проведения дедупликации.

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

Вопрос: Почему вы считаете, что кэш в данном случае не сможет точно также эффективно  закэшировать одинаковые блоки, даже если они лежат в разных местах?

Ответ: Потому что кэш не знает ничего о содержимом блоков, он знает только о расположении его. Кэш помещает в себя "блок номер 12037", "блок номер 34560" и "блок номер 545200". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они  их видит только “по номеру”.
В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один.
Ситуацию пояснят рисунки:

deduped-cache1

deduped-cache2

Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"

18/0.149

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.