12 октября 2010 г.

ИТ-афоризмы

Во натолкнулся на несколько забавностей...  :)

“A fool with a tool is still a fool.”
Дурак с инструментом…  все равно дурак.

“Know what you are automating before you automate it.”
Узнайте, что вы автоматизируете, до того, как начнете автоматизировать.

“Real men don't click.”
Реальные пацаны не кликают. (в смысле пользуются только CLI ;) )

“Windows is like a submarine. As soon you open up a window, the problems begins”
Windows как подводная лодка: проблемы начинаются сразу, как только вы откроете окно.

You can have it done right, cheap, or quick. Pick two.
Вам все сделают правильно, дешево и быстро…  (подчеркните только два варианта)

“OSI layer 8 error”.
Ошибка восьмого уровня модели OSI.

“Nothing is permanent, except for temporary solutions.”
Ничто так не постоянно, как временное.

“There are only 2 types of people..people that have experienced a harddisk crash and people that are going to expierence a harddisk crash!”
Существуют всего 2 типа людей: те, кто не понаслышке знает, что такое крэш диска, и те, кто уже скоро об этом узнают…

"There are only 10 types of people in the world: Those who understand binary, and those who don't"
В мире существуют только 10 типов людей: тех кто понимает двоичное исчисление и тех кто нет.

10 октября 2010 г.

Нет повода не...

Сегодня я совершенно случайно обнаружил, что день-то праздничный. Это, конечно, не День взятия Бастилии, но повод закусить, определенно, есть... :) По календарю сегодняшнее число 10.10.10. Безмерно ликовать и радоваться можно по двум причинам:

-во первых, 101010 само по себе красиво. Особенно, если вспомнить об этом в 10:10...

-а во вторых, любой ИТ-шник сразу переведет его из bin в dec и получит... о чудо... 42 !!! , что, как всем известно, есть ответ на "Самый главный вопрос жизни, Вселенной и вообще"... ;)  

PS я вот все думаю над вопросом...  %(   может "приборы?"

PPS "Life, the Universe & Tape or Disk" еще раз, для тех кто читал оригинал..  :)))

8 октября 2010 г.

Статья "Эффективное хранение данных"

Журнал опубликовал мою статейку. Исключительно в целях бессмысленного повышения энтропии Вселенной запощу ее и сюда  ;) . Оригинал здесь.

PS мне сказали, что название должно быть именно таким...  :)  от этого и плясал...

"Люди общаются друг с другом посредством слов. Однако некоторые слова от частого использования затираются и теряют свой смысл. От регулярного бездумного употребления превратилось в бессмыслицу и слово “эффективность”. Мы постоянно видим его в маркетинговых брошюрах, слышим в докладах конференций и презентациях продуктов. Постепенно слово перестало что-либо означать, стало просто обязательным атрибутом расхваливания товаров.

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

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

Начнем с обсуждения очень актуальной проблемы. Мир тонет. Наша маленькая планета буквально захлебывается в колоссальных объемах данных, которые с каждым годом увеличиваются в сумасшедшей прогрессии. Для борьбы с потопом можно, конечно, использовать самый простой метод — постоянно приобретать новые емкости, тем самым, увеличивая доступное пространство хранения. К сожалению, этот способ хорош только на первых порах. После достижения некого критического уровня суммарных емкостей в любой компании остро встают вопросы роста капитальных и операционных затрат (из-за необходимости увеличения площадей серверных комнат для размещения нового оборудования), увеличения численности группы администрирования СХД и поиска дефицитных дорогостоящих “стораджевиков”. Каждый год приходится выкладывать все возрастающие суммы на сервисную поддержку. Мониторинг такого комплекса и управление им превращаются в кошмар. Начинают играть заметную роль факторы, которые раньше совсем не принимались во внимание. Например, стоимость электропитания или отвод тепла из серверной. Безрадостная картина, не правда ли?

К счастью, кроме способа экстенсивного расширения ресурсов существует метод их более интенсивного использования. Для начала задумаемся, каким образом потребляется емкость хранения. Для примера рассмотрим полезные данные размером 1 Tбайт. Помещенные в некую СУБД за счет разреженности они могут занимать заметно больший объем, скажем 2 Tбайт. Объем данных со временем растет, и администратор СХД просто обязан выделять тома с неким запасом по емкости. Допустим, в текущий момент утилизация выделенных томов равна 50%, что в итоге приводит к потреблению 4 Tбайт. Для защиты информации применяется RAID. При использовании зеркалирования RAID10 нам потребуются 8 Tбайт физической емкости. Катастрофоустойчивое решение предполагает реализацию репликации на удаленный дисковый массив, и это приводит к потреблению дополнительных 8 Tбайт. Полное и инкрементальное резервное копирование за неделю потребует не менее 2,5 Tбайт, а для его выполнения в горячем режиме необходимо использовать функциональность мгновенных снимков, что в среднем увеличивает потребление ресурсов хранения еще на 20% от полезного объема. Средам тестирования и разработки также нужна физическая емкость, скажем 500 Гб в RAID5. Итого, в нашем примере при хранении 1 Tбайт полезной информации придется выделить объем более 19 Tбайт. В англоязычной литературе для обозначения потребляемого брутто-объема данных используется термин data footprint. Интересно, что даже небольшое сокращение объема полезных данных, например за счет их архивирования, приведет к значительному снижению потребляемой емкости.

Сокращение data footprint заметно снижает капитальные и операционные затраты и поэтому является одной из основных задач оптимизации хранения данных. Давайте рассмотрим две современных технологии, которые компания EMC предлагает для решения этой задачи: динамическое выделение ресурсов хранения (virtual provisioning) и компрессия данных.

Динамическое выделение ресурсов хранения позволяет не резервировать заранее дисковое пространство под рабочие тома, а автоматически делать это из общего пула ресурсов по мере роста данных. В дисковых массивах CLARiiON в новой 30-й версии операционной среды Flare функциональность пулов была значительно расширена. Поддерживаются RAID 5, 6 и 10. В пуле можно одновременно создавать как классические чуть более производительные “толстые” тома с предварительным резервированием ресурсов, так и динамические “тонкие” тома. Оптимизирована технология динамического расширения пулов при добавлении новых дисков. Теперь это происходит без использования функциональности MetaLUN.

Если серверы заказчика работают с операционной системой Windows Server 2008, для сокращения data footprint в пулах можно применить технологию изъятия неиспользуемых ресурсов томов (LUN shrink). Видимый размер тома уменьшается мгновенно. Реальное же его сокращение реализуется в дисковом массиве при помощи фоновых процессов, которые выискивают 8-Kбайт блоки, заполненные нулями, и возвращают их обратно в пул.

Подобная технология подойдет и владельцам других операционных систем. Для освобождения неиспользуемых ресурсов рекомендуется провести миграцию данных на “тонкие” тома. При этом 8-Kбайт блоки нулей, как и в случае технологии LUN shrink, возвращаются в общий пул. Данная функциональность работает и при миграции данных с других дисковых массивов с помощью SANcopy.

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

Для дополнительного снижения потребляемой емкости можно воспользоваться компрессией томов. При включении эта функциональность совершенно прозрачно для пользователя перемещает данные на “тонкие” тома, освобождая неиспользуемые ресурсы. Во время такой миграции прямо “на лету” обнаруживаются и сжимаются повторяющиеся элементы данных в блоках по 64 Kбайт. К блокам, в которых можно сжать менее 8 Кбайт данных, компрессия не применяется. В дальнейшем для снижения нагрузки на дисковый массив компрессия работает в фоновом режиме, но не постоянно, а только при достижении пороговых значений. Процесс начинается при любом из двух условий: было изменено 10% данных тома или модифицировано 10 Гб информации. При чтении данных сжатая информация загружается в кэш и там автоматически распаковывается. Данные на диске остаются в компрессированном виде. Для контроля нагрузки на процессоры дискового массива каждому тому можно устанавливать один из трех приоритетов. При низком приоритете дополнительная загрузка CPU не превышает 15%.

Независимое тестирование компании Enterprise Strategy Group показало, что 100- Гб том с файловой системой NTFS, заполненный 75 Гб различных данных (видео, документы MS Office, текст, бинарные файлы), после применения компрессии стал занимать всего 54 Гб. Поразительные результаты, правда? Другие тесты показывают, что особенно эффективно использовать сжатие данных в виртуальной среде VMware.

В NAS-устройствах хранения EMC Celerra потребляемую емкость можно сократить за счет одновременного применения компрессии на уровне блоков и дедупликации файлов. Эффект экономии дискового пространства может достигать 50%. Как это работает? Специальный фоновый процесс сканирует устройство хранения и по характеристикам последнего времени доступа и модификации идентифицирует неактивные файлы. Далее такие файлы сжимаются при помощи механизма компрессии, аналогичному используемому в дисковых массивах CLARiiON. Одновременно с этим выполняется вычисление уникального хэша данных файла. Результат записывается в специальную скрытую область. Если хэшы нескольких файлов совпадают, то вместо всех дублированных копий записываются короткие ссылки на оригинальные данные. При модификации файлов перестраиваются ссылки только на измененные блоки. Такой подход позволяет значительно повысить скорость доступа к файлам большого размера.

Еще один эффективный способ сокращения издержек на хранение данных и понижения общей стоимости владения (TCO) — это динамическое выделение ресурсов в зависимости от ценности информации и требований производительности доступа к ней. Именно для этих целей компания EMC предлагает технологию FAST (Fully Automated Storage Tiering), которая позволяет автоматизировать перемещение данных в соответствии с уровнем активности доступа к ним. Вкратце рассмотрим, как это работает. В единый пул ресурсов могут быть объединены накопители трех разных типов flash (EFD), FC и SATA. Дисковый массив постоянно осуществляет мониторинг загрузки томов, на которых включена функциональность FAST, и в соответствии с активностью доступа к ним перемещает блоки данных на наиболее подходящий уровень хранения. “Горячие” данные попадают на производительные накопители flash. Редко требуемые размещаются на дисках SATA. Для обеспечения оптимального соотношения гранулярности перемещения и уменьшения дополнительных накладных расходов, связанных с внутренним копированием данных, данные перемещаются блоками в 1 Гб. Перенос информации осуществляется в соответствии с заранее установленными расписаниями. Приоритеты размещения данных на дисках с различными уровнями производительности могут задаваться специальными правилами.

Возвращаясь к главной теме этой статьи, опять зададимся вопросом: “В чем заключается эффективность?”. Дело в том, что технология FAST позволяет добиваться очень высоких показателей цена/производительность. Оптимальное для каждого конкретного заказчика сочетание накопителей различных типов, объединенных в общий пул ресурсов с заданными требованиями к производительности, позволяет гибко организовывать хранение данных, минимизируя удельную стоимость хранения. При этом решение будет адаптивным. Оно станет динамически приспосабливать комплекс хранения под изменяющиеся нужды бизнеса. Упрощение первоначального планирования размещения данных и отсутствие необходимости постоянной ручной оптимизации производительности дает возможность заметно снизить затраты на управление комплексом хранения. (способы расчета конфигурации под FAST обсуждались здесь)

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


PS Картинка к комментарию 
Я проверил на демо-массиве, все три типа RAID поддерживаются.

4 октября 2010 г.

Встреча со Стивом Тодом

FYI
К сожалению, только для Питерцев...  :(  ну, а тем кому повезло ;) , настоятельно рекомендую...

-----Original Message-----
From: emc-academic-alliance-russia-newsletters@googlegroups.com
Sent: Monday, October 04, 2010 10:41 PM
To: EMC Academic Alliance Russia Newsletters
Subject: EMC Academic Alliance Russia Newsletter #35/10

Уважаемые коллеги!


Сотрудник корпорации ЕМС Стив Тод  (Steve Todd)
http://stevetodd.typepad.com/my_weblog/steve-todd-curriculum-vitae.html
занимает должность инженера.
Однако его интересы простираются далеко за пределы его должностных
функций.
Его врожденные способности к систематизации информации и искренний
интерес к информационным технологиям, вместе со способностями к работе
с аудиторией привели к тому, что Стив
- написал и издал книгу по основам корпоративного предпринимательства,
- регулярно проводит публичные выступления как перед сотрудниками
различных подразделений корпорации, так и перед сотрудниками других
корпораций и студенческой аудиторией различных стран.


Стив приезжал и в Россию год назад.
Его выступление запомнилось непринужденностью обстановки, яркой
харизмой и умением просто рассказать о сложном.
Уверен, те кто был на встрече с Тодом захотят прийти снова.
Не только захватывающе, но и поучительно посмотреть как технический
специалист  может позиционировать себя в качестве собеседника и
соучастника.


Встречайте:


Стив Тодд, заслуженный инженер компании EMC,  прочитает лекцию "Global
High-Tech Innovations" сразу в двух петербургских вузах:


7 октября в четверг в 16 30 в Санкт-Петербургском государственном
университете информационных технологий, механики и оптики (ИТМО,
Кронверский пр, актовый зал)
и


8 октября в пятницу в 13 00 в Санкт-Петербургском государственном
университете (СПБГУ, Петергоф, Университетский пр., д.28, мат-мех,
ауд. 405)


Стив Тодд является заслуженным инженером в корпорации EMC.  Созданная
им программная реализация технологии RAID была одной из первых и
наиболее успешных за всю историю индустрии хранения данных. В мире
установлено более полумиллиона устройств хранения CLARiiON, которые
защищают наиболее важную и критичную информацию планеты с помощью
созданных Стивом алгоритмов. Стив является (со)автором более чем 160
патентов в различных областях информационных технологий.
Лекция будет посвящена следующим основным вопросам:
-    Глобализация инноваций
-    Последние инновационные достижения в мире, созданные разработчиками
программного обеспечения
-    Изменение корпоративной культуры в области инноваций на примере
корпорации EMC
-    Советы по успешной карьере в области ИТ


Блог Стива Тодда: http://bit.ly/aaMVWi
Книга Стива Тодда "Инновации, влияющие на мир" http://www.booklocker.com/books/4145.html


Регистрация:
http://vkontakte.ru/event20037521  - ИТМО
http://vkontakte.ru/event20043544    - СПБГУ


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

3 октября 2010 г.

Приостановка передачи в SAN

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

Одними из наиболее распространенных причин приостановки передачи данных в фабрике сети SAN являются процессы перестроения (Build Fabric) и реконфигурации фабрики (Reconfigure Fabric).

Для начала разберемся в принципиальных различиях между ними.
Процесс Build Fabric (BF) является не разрушающим (non-disruptive), т. е. хотя передача данных на какой-то небольшой период времени приостанавливается, но никакая информация не теряется. Это связано с тем, что списки Domain ID не обнуляются и адресация всех устройств гарантированно сохраняется. Principal Switch, приоритеты и маршруты передачи остаются прежними. Открытые exchange не сбрасываются.

Процесс Reconfigure Fabric (RCF), напротив, является разрушающим (disruptive) и передаваемые данные всегда теряются. Ведь списки Domain ID непременно сбрасываются и Domain ID назначаются заново. Если Domain ID какого-либо коммутатора изменился, после обязательного повторного логина в фабрику всех оконечных устройств изменятся и адреса соответствующих N-портов. При RCF весь трафик класса F прерывается. Обязательно начинается процесс перевыборов Principal Switch. По времени RCF продолжительнее, чем BF.

Ниже приведены несколько примеров ситуаций, для разрешения которых используются эти процессы.
  • Новый коммутатор с чистым списком Domain ID присоединяется к уже функционирующей фабрике. Ему нужно назначить Domain ID, поэтому начнется процесс BF.
  • Сливаются две продуктивные фабрики, имеющие собственные списки Domain ID. При этом, одинаковых Domain ID в этих фабриках нет. В этом случае необходимо вместо двух независимых Principal Switch выбрать один. В ходе процесса BF выбирается новый единый Principal Switch.
  • Предыдущий случай, но в фабриках есть совпадающие Domain ID. Конфликт надо разрешить, поэтому начинается процесс RCF.
  • Соединяются два новых коммутатора с девственно чистыми списками Domain ID. Начинаются выборы Principal Switch и, соответственно, процесс BF (или RCF).
  • Если по каким-то причинам разрывается upstream principal ISL. Для нахождения альтернативного пути запускается BF. Если такой путь не найден, то после BF проходит RCF.
  • Если какой-то коммутатор пытается достигнуть Domain ID, которого нет в фабрике, Principal Switch начинает RCF.
  • В случае наличия сегментированных портов, модернизация микрокода может вызвать BF или даже RCF.
  • При разрыве trunk master в 1Gbps и 2Gbps коммутаторов Brocade запускается BF.
  • Если Principal Switch выключился или начал перегружаться, начинаются перевыборы и процесс RCF.
  • Если по какой-то причине процесс BF закончился не удачно (не были получены пакеты подтверждения), начинается RCF.
  • В коммутаторах Cisco вы можете принудительно вручную рестартовать домен. При disruptive restart запускается RCF, при nondisruptive restart – BF. Сделать disruptive restart обязательно придется, если захочется сменить текущее значение Domain ID (например, для разрешения конфликта). Изменение параметра Preferred Domain ID по понятным причинам потребует всего лишь nondisruptive restart.

Избежать задержек передачи данных в результате BF или RCF не возможно. Ведь эти процессы предназначены для обеспечения жизнедеятельности самой фабрики. Однако, в некоторых случаях можно значительно сократить время BF и минимизировать его влияние на коммутаторы. Так, в коммутаторах Cisco при включенной опции fast restart, выход из строя Principal Link не вызывает полноценный Build Fabric. Если между коммутаторам существует дублирующий линк, то процесс его назначения Principal Link затронет не всю VSAN, а только два соответствующих коммутатора и займет всего несколько миллисекунд. Если дублирующего линка нет, то опция, конечно не поможет…

Остается вопрос, как же все-таки минимизировать воздействие описанных выше процессов на SAN? Ответ вы, конечно, знаете сами. Обязательное построение сети хранения в виде двух физически или логически (VSAN) изолированных друг от друга redundant фабрики вкупе с ПО multipathing!!!

Добавлено Brocade утверждает,что в современных релизах FOS Reconfigure Fabric никогда не происходит.  Охотно верю.