Windows в Clariion

Где-то с год назад я натолкнулся на очень интересный пост о набившей уже многим оскомину теме Windows в Clariion. Он был напечатан в блоге одного из девелоперов FLARE старой гвардии, известного популяризатора инновационного подхода к разработке продуктов Стива Тода. И вот я все-таки сподобился его перевести. Оригинал здесь.


"Решение о Windows
Одним из наиболее интересных моментов в дискуссиях по поводу CLARiiON является факт того, что внутри него “крутится” Windows XP embedded. Некоторые читатели спрашивали меня об этом. Также я обнаружил множество запросов в Google с попыткой найти на моем сайте побольше информации на эту тему. Многие любопытствуют, почему и когда было принято решение об использовании Windows? Ведь в 90-е годы CLARiiON не был продуктом на Windows.
Хорошо, у меня есть ответы. Предупреждаю, что они могут несколько отличаться от других ответов на эту тему, которые вы уже, возможно, получали. Мои воспоминания являются точкой зрения программного архитектора.
Как я помню, была необходимость в смене архитектуры CLARiiON по одной основной причине: конкуренция против EMC.

В конце 90-х CLARiiON был продуктом, разработанным компанией Data General. Я участвовал в создании программной архитектуры микрокода CLARiiON, известной как FLARE. Начиная с 80-х я отвечал за алгоритмы RAID, кэш на запись и обработки ошибок (горячее восстановление, переключение и обратное переключение в случае сбоев компонент), а также за все связанное с целостностью данных.

Архитектура, основанная на процессах
Первоначально программная архитектура FLARE была просто набором процессов. Для каждого диска был свой процесс. Был процесс для обработки запросов на чтение и запись от приложений на серверах. Был процесс перестроения RAID, фоновый процесс верификации, процесс для выполнения настроек и т. д. Операционная среда для всех этих процессов была самодельной проприетарной системой, которая называлась HEMI (потому, что планировщик в ней использовал полусферический (hemispherical) алгоритм).

В первые 6 или 7 лет существования мы добавляли в нее новую функциональность. Мы добавили поддержку протокола SCSI. Мы добавили поддержку дисков горячей замены. Мы добавили кэш на запись, поддержку новых уровней RAID, улучшенную производительность и добавили поддержку графического пользовательского интерфейса. Мы ушли от фиксированного количества дисков при помощи возможности добавления новых полок. Мы добавили поддержку SAN (например, LUN маскинг). Первоначальная архитектура вобрала в себя все это и доказала свою масштабируемость и сервисо-пригодность.

И по мере того, как в середине и конце 90-х рынок хранения данных просто взлетел, парни, заведующие бизнесом CLARiiON, все чаще стали посматривать на огромные прибыли, которые могли принести системы хранения верхнего уровня, такие как EMC Symmetrix. Эти продукты уже мешали друг другу в случае продаж, когда заказчик рассматривал возможность приобретения “нажнего хай-энда” либо “верхнего мидренджа”.

Symm против CLARiiON
Определенно, Symmetrix был сильным игроком и одна из основных сложностей конкуренции с ним была в том, что Symm имел возможность соединения с огромным количеством серверов (обеспечивая это большим объемом кэш). Но DG в основном думала не о аппаратном обеспечении, а о допольнительных программных возможностях, которые генерировали громадные доходы: SRDF и TimeFinder. CLARiiON не имел такой функциональности. Для все большего количества заказчиков удаленная репликация и возможность создания мгновенных снимков стали основополагающим фактором, а CLARiiON ими не обладал.

К счастью, CLARiiON имел несколько других выдающихся достоинств. Symm (в то время) не имел алгоритмов работы с RAID-5, зеркалируемого кэш на запись и не обладал простым графическим пользовательским интерфейсом (Navisphere). Но без удаленной репликации и возможностей создания мгновенных снимков CLARiiON не мог конкурировать. Удаленная репликация и мгновенные снимки указывали на то, что программная архитектура CLARiiON, основанная на процессах имеет некоторые недостатки.

Уровни против процессов
Как я уже упоминал, FLARE имел front-end процесс для обработки входящих запросов от приложений на серверах. Этот процесс также поддерживал кэш на запись. Когда данные из кэш перемещались на диск, front-end процесс должен был "открыть коннект" с соответствующим другим процессом и послать ему "сообщение". А так как количество дисков сначала возросло с 20 до 30, потом до 40 и, в конце концов, до 120, во FLARE  добавлялось все большее и большее число процессов. Коннекты между всеми этими процессами реализовывались огромным количеством пайпов, через которые пересылалось чудовищное количество сообщений.

Решение о том, куда все-таки вставить функциональность удаленной репликации и мгновенных снимков, не было очевидным. Добавление нового процесса привело бы к еще большим “пляскам с балалайкой”. Модификация существующих процессов размыло бы четкие границы архитектуры и нарушила бы инкапсуляцию функций. Существовали опасения насчет производительности и поддержки архитектуры.
Было бы здорово, если бы FLARE поддерживала “включение” этой функциональности более реализуемым способом не тревожа функциональность таких компонент как кэш на запись и алгоритмы RAID. Ну, типа как в многоуровневой реализации поддержки устройств. Эй, а разве Windows не использует отличную многоуровневую модель стека устройств?

Реакция на решение
Вы можете себе представить, с каким скептицизмом внутри компании было встречено известие о переводе FLARE на Windows embedded. На вопросы о том, будет ли FLARE показывать заказчикам “синие экраны” в шутку отвечали: “мы просто не собираемся для этого поставлять экраны” ;>). Мягко говоря, это было несколько спорное внутренне решение.

Заказчики также отнеслись к нему скептически. Один из наших вице-президентов встречался со многими клиентами, которые регулярно задавали ему вопросы об уровне качества нового продукта. К его чести, он признавал, что переход на новую архитектуру в самом начале может вызвать некоторые проблемы с качеством. Однако, DG и не имело причин скрывать проблемы с качеством, т. к. в заднем кармане у нее был такой козырь, как DAQ. ПО Disk Array Qualifier все еще гоняет свой комплект тестов целостности данных и проверяет на прочность новые решения на базе Windows. DAQ запускался как на старой, так и на новой архитектуре благодаря так называемым “крючкам качества” которые всегда были частью FLARE и которые работали на Windows. Кэш на чтение мог быть полностью протестирован.
Это удовлетворяло опасения заказчиков. И когда они поняли, что многоуровневый стек устройств обеспечивает, во первых, лучшую производительность и, во вторых, возможность внедрения функциональности в конкретный уровень не затрагивая другой существующий код, они начали инвестировать в новую архитектуру.

Это работает
Разработчики программного обеспечения для CLARiiON проделали отличную работу перегруппируя различные части процессов архитектуры HEMI в разные уровни стека драйверов Windows. Производительность была превосходной (особенно после того, как кэш на запись был портирован без проблем). Новые драйвера устройств удаленной репликации и мгновенных снимков реализованы в виде уровней поверх базовой функциональности HEMI.

Смелое решение оправдало себя. DG было приобретено EMC. На сколько хорошо EMC продало решение, основанное на Windows? Посмотрите последний пресс-релиз об анонсе массивов CX в начале августа (прим. пост был опубликован 28 августа 2008 г.). EMC докладывает о продаже более, чем 300000 CLARiiON, каждый из которых имеет доступность 99.999. Качество , производительность, гибкость и доход. Откровенно говоря, более 300000 CLARiiON, работающих по всему миру, все еще удивляют меня. Вот что случается, когда стораджевый продукт куплен стораджевой компанией.
Дополнительные многоуровневые драйверы разрабатывались годами и о некоторых из них я надеюсь написать в будущих постах.

Стив"

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