Системы хранения данных как предмет разговора
Archive for Октябрь 2009
Любопытные сведения найдены в блоге одного из сотрудников NetApp:
Нет времени писать на этой неделе большие трактаты. Поэтому отделаюсь маленькими заметками.
Не так давно я писал о том неожиданном эффекте, к которому приводит рост объемов. Так, например, рост объема жестких дисков практически лишает пригодности 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%, на каждом переданном гигабайте, просто по причине набегания этой ошибки.
Поиграть с величинами и понять масштабы проблемы можно, например, в онлайн-калькуляторе.
С удовольствием объявляю о пополнении в русскоязычной библиотеке NetApp Best Practices на сайте компании Netwell:
Руководство по наилучшим методам использования систем хранения NetApp с MS Exchange 2007®
Brad Garvey, Shannon Flynn | NetApp | TR 3578
Руководство по установке и настройке дедупликации в системах NetApp FAS и V-Series
Carlos Alvarez | NetApp | TR-3505-0309
Один из клиентов NetApp - фотохостинг Flickr, принадлежащий ныне Yahoo, взял недавно новую высоту.
Четыре миллиарда закачанных пользовательских фотографий, при этом следует помнить, что при выбранной Flickr архитектуре хранения, каждая фотография хранится в виде 4-5 файлов разного разрешения, то есть суммарное количество файлов хранения еще в 4-5 раз больше.
Я уже писал про Flickr, с некоторыми подробностями по используемой архитектуре, в посте ранее, где приводились некоторые подробности на конец 2007 года. Думаю, что можно проэкстраполировать те данные, чтобы получить представление о сегодняшней ситуации.
Однако 4 миллиарда это не рекорд. Так, другой клиент NetApp, компания Facebook, хранит свыше 15 миллиардов фотографий (на апрель этого года).
Не совсем по тематике блога о системах хранения, но тем не менее весьма любопытный документ был недавно опубликован.
Те же авторы, 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
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". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они их видит только “по номеру”.
В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один.
Ситуацию пояснят рисунки:
Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"