11.11.2007

Oracle и BEA. Несостоявшаяся сделка.

Хроника событий:

  1. 12 октября 2007

Oracle заявляет о том, что 9 октября 2007 сделал предложение совету директоров BEA, в котором предлагает приобрести компанию по цене $17.00 за акцию при рыночной цене акций $13.62. По заявлениям руководства Oracle, предлагаемое поглощение будет исключительно дружественным. Oracle обязуется обеспечить поддержку существующих на сегодняшний день внедрений BEA, точно так как же, как ранее в случае с PeopleSoft и Siebel.

  1. 25 октября 2007

Совет директоров BEA заявляет, что предложение Oracle явно занижено. BEA после консультаций с независимыми аналитиками пришла к мнению, что объективная стоимость компании составляет $21.00 за акцию. Письмо, излагающее позицию BEA, направлено в Oracle.

  1. 25 октября 2007

Буквально через несколько часов Oracle заявляет, что $21.00 за акцию неприемлемо высокая цена и для Oracle, и для любых других претендентов. Поэтому компания остается при своем первоначальном мнении и предлагает $17.00 за акцию. Кроме того, Oracle устанавливает срок действия своего предложения до 28 октября.

  1. 28 октября 2007

Oracle заявляет, что срок действия его предложения истек. По заявлению компании, «если держатели акций BEA недовольны решением совета директоров, то это их задача – предпринять соответственные действия, никак не задача Oracle».

Итого, сделка не состоялась.

Oracle сделал очередную попытку приобрести разработчика middleware, но сделка опять не удалась. Напомним, что до этого Oracle пытался приобрести JBoss, но JBoss предпочел объединиться с Red Hat вместо того, чтобы быть купленным Oracle.

Собственно говоря, ничего удивительного в том, что разработчики middleware не торопятся продать свои компании, нет. Направление SOA сейчас популярно, и нет никакого резона продавать свой бизнес в этой области. Гораздо более интересны мотивы Oracle. Ведь у компании есть свое направление middleware, в котором активно ведутся разработки. С чем связаны такие активные попытки приобрести его аналоги? Это способ устранить конкурентов или компания не удовлетворена темпом и качеством своих разработок и хочет сменить платформу?

Ответить однозначно здесь, конечно, нельзя. Скорее всего, все же первое – компания пытается обеспечить себе доминирование на рынке. Только вот методы при этом наводят на мысль, что сделать это иначе, как купив конкурентов, компания не может.

10.11.2007

Novell уволила разработчиков AppArmor

Зачем нужна AppArmor?

AppArmor – это реализация мандатного контроля доступа для Linux-систем. Не будем вдаваться глубоко в технические детали. Скажем лишь, что мандатный контроль доступа позволяет достичь уровня безопасности, принципиально невозможного для традиционного (дискреционного) контроля доступа, используемого в подавляющем большинстве современных операционных систем.

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

История и нынешнее состояние AppArmor

Технологическая основа AppArmor была создана небольшой компанией Immunix, специализировавшейся на разработке решений для обеспечения безопасности Linux-систем.

В 2005 году Immunix была куплена Novell, после чего продукт был переименован в Novell AppArmor, а ключевые разработчики продолжили работу над ним уже как сотрудники Novell. Этот факт позволил Novell включить AppArmor в свой дистрибутив SuSe Linux и обеспечить его поддержку.

Смогла ли бы Novell обеспечить поддержку AppArmor, не имея его разработчиков в штате? Вряд ли. Мандатный контроль доступа – не только очень мощная технология, но и достаточно сложная. AppArmor всегда позиционировался как простая в использовании система мандатного контроля доступа. Но относительно простая она лишь для пользователя, в разработке и поддержке она ничуть не проще любой другой.

На сегодняшний день AppArmor стал достаточно популярен. В частности, Canonical включила его в новую версию дистрибутива Ubuntu, а Mandriva – в Mandriva Linux 2008. Казалось бы, решение пользуется популярностью, и логично развивать и продвигать его дальше.

Но тут Novell увольняет пятерых ключевых разработчиков, включая лидера проекта (подробнее - http://www.news.com/8301-13580_3-9796140-39.html).

Войдет ли AppArmor в следующие версии SuSe?

Novell заявляет о том, что продолжит поддерживать и обновлять AppArmor. По заявлениям компании, делать это она планирует, сотрудничая с сообществом, образовавшимся вокруг AppArmor.

Возможно ли это? Включать обновленный AppArmor в дистрибутив – конечно да. А вот обеспечить адекватную поддержку комплексной технологии, не имея ее разработчиков в штате, крайне сложно.

Главный вопрос. Почему Novell так поступила? В чем смысл происходящего?

Не претендуя на абсолютную точность, рискнем все же сделать достаточно очевидные выводы. Похоже, Novell не заинтересована в AppArmor и избавилась от этого направления разработки как от непрофильного актива.

Дело в том, что на сегодняшний день существует две системы мандатного контроля доступа – SELinux и AppArmor. Первая из них рассчитана на предельную строгость. Вторая – на простоту настройки. Но простота настройки – явно не первоочередная задача, когда речь идет о системе мандатного контроля доступа. Поэтому подавляющее большинство серьезных внедрений основано на SELinux. AppArmor же используется, как правило, для тестирования и изучения поведения приложений.

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

Какое будущее ждет AppArmor?

Уволенные разработчики заявляют о том, что не собираются бросать проект. На сегодняшний день они создали компанию Mercenary Linux (http://www.mercenarylinux.com/), которая будет разрабатывать AppArmor и оказывать консультации по его использованию. Так как именно эти люди создали AppArmor и координировали его разработку все последние годы, их позиция абсолютно логична и понятна. Если они сейчас перестанут поддерживать проект, велик риск того, что пока вокруг него будет формироваться новая команда, он отстанет в своем развитии от аналогов и будет забыт.

Кроме того, разработчики заявили, что если какая-либо компания заинтересована в развитии AppArmor и хочет приобрести Mercenary Linux, то они всегда готовы обсудить честные предложения.

07.11.2007

Сетевые файловый системы

Введение



Идея сетевых файловых систем далеко не нова. Далеко не нова - это значит, что первые реализации файловых систем, внешних по отношению к физическим ЭВМ, появилась в начале 80х - это файловые системы для VAX-VMS кластеров. Эту идею развивали многие компании, в результате чего мы по сути имеем несколько фундаментальных концептов разделяемых файловых систем, не говоря уже о количестве конкретных реализаций данных концептов. Фундаментальные концепты включают сетевые файловые системы (NFS), параллельные файловые системы (Lustre) и симметричные блочно-разделяемые файловые системы (GFS и иже с ними).

Сетевые файловые системы (NFS)



Сетевая файловая система (NFS) - достаточно простое, дешевое и привычное в мире Unix решение для организации разделяемых данных. Спецификации (как и многие реализации) NFS имеют прямое отношение к SUN Microsystems. Всего существует 4 различных спецификации протокола NFS, хотя первая его версия так и не вышла в свет, оставшись навсегда во внутренних тестовых лабораториях SUN. Поэтому наш обзор мы начнем с NFSv2. Напомним, что это концепт удаленной файловой системы, предоставляющей доступ на файловом уровне.

NFSv2


Спецификация NFSv2, выпущенная в далеком 1989 году, полагалась исключительно на UDP в качестве транспортного протокола. Это позволяло создать достаточно простой сервер, который не имел внутреннего состояния (Stateless), что, соответственно, не давало никаких гарантий транзакционности файловых операций (например потому, что файловые операции могли выполняться сервером в порядке дохождения пакетов, который, вообще говоря, может отличаться от порядка операций, задуманного клиентом). Файловые блокировки также были реализованы вне основного протокола, что существенно ограничивало производительность. В частности, многие реализации просто начинали poll'ить заблокированный файл, создавая паразитный трафик и ненужную нагрузку на сервер. Добавим сюда абсолютное отсутствие аутентификации клиента на сервере (мы же не полагаемся на IP-адрес, как на данные аутентификации, правда?) и предположение об однородном пространстве соответствий пользователей и их идентификаторов, что принято было обеспечивать с помощью, мягко говоря, не самого безопасного протокола - NIS, и мы поймем, насколько эта версия NFS слаба и незащищена.

Итого, из плюсов системы можно отметить только:
  1. Простоту реализации и развертывания
  2. Абсолютную индифферентность "сервера-без-состояния" к происходящему в сети. Например, клиент запросто мог перезагрузиться и продолжить запись в файл как ни в чем ни бывало.
Зато из недостатков:
  1. Фактическое отсутствие контроля доступа и шифрования информации.
  2. Необходимость использования в "доверенной сети".
  3. Необходимость централизации пользовательской информации.
  4. Отсутствие транзакционности.
  5. Отсутствие поддержки блокировок.
  6. Поддержка исключительно синхронных операций записи.

NFSv3


Спецификация NFSv3 вышла в чуть менее далеком 95м, хотя, наверное, это знаменательное событие было несколько оттенено запуском Windows 95 =). В новой (по тем временам) спецификации было 4 фундаментальных преимущества перед версией v2. Вот они:
  1. Возможность использовать TCP в качестве транспортного протокола.
  2. Возможность использовать 64-битные размеры и смещения в файлах, что позволяло использовать большие файлы (более 4Гб).
  3. Поддержка асинхронного ввода-вывода.
  4. Реализация файловых блокировок в протоколе.
Остальные фундаментальные недостатки, вроде абсолютного отсутствия аутентификации и необходимости использовать централизованный сервис предоставления пользовательской информации, никуда не делись.

NFSv4 aka текущая версия


Данная спецификация была разработана в 2000 году и пересмотрена в 2003. В то время спецификация уже вышла из-под контроля SUN (как в свое время сделали немало других спецификаций, например, спецификации Java). Из принципиальных улучшений стоит отметить:
  1. Поддержку аутентификации хостов и пользователей (например, средствами Kerberos).
  2. Поддержку шифрования информации.
  3. Поддержку "продвинутых" методов клиентского кэширования.
В спецификации есть дополнительно много мелких улучшений (со списком можно ознакомиться в RFC3530).

Из общих недостатков подобных решений стоит отметить крайне неважную масштабируемость. Например, использовать NFS в качестве файловой системы для кластеров СУБД по крайней мере наивно. Для каждой задачи есть свой инструмент, поэтому мы перейдем к другой крайности - параллельным файловым системам.

Параллельные файловые системы (Lustre)



Авторы утверждают, что название этой файловой системы произошло от смешения слов Linux и cluster, хотя лично нам аналогия с люстрой кажется несколько более очевидной. Это файловая система обладает максимальной производительностью, масштабируемостью и является наиболее успешным примером файловой системы, которая, например, используется в MPP-системах, таких как вычислительные кластера. Это байт-ориентированная файловая система. Принцип устройства файловой системы достаточно комплексен, так что рекомендую читать более одного раза =). Базовых компонент три:
  1. Сервер метаданных (возможно с активным/пассивным резервированием). Данный сервис отвечает за метаданные, такие как структура директорий, атрибуты и имена файлов, а также указывает на положение "объектов", составляющих файл, на экземплярах следующей компоненты.
  2. Сервер хранения. Это сервер, к которому может быть подключено несколько "целей хранения", или, если по простому, блочных устройств. В настоящее время на этих блочных устройствах используется несколько видоизмененная файловая система ext3 для хранения объектов. Типичная конфигурация сервера хранения предусматривает наличие от 2-х до 8-ми "целей", каждая объемом до 8 Тб. Общий объем файловой системы равен сумме объемов целей, ее составляющих.
  3. Клиент. Без особых комментариев. Клиент находит необходимый ему файл (а точнее, объекты его составляющие), пользуясь сервером метаданных. Затем блокирует определенный диапазон смещений внутри файла и обращается к серверам хранения, которые непосредственно модифицируют данные на своих "дисках".
При подобной инфраструктуре выдерживается также следующее правило: если файл влезает в один "объект", то этот объект хранится на одном сервере, в противном случае производится stripping файла между несколькими серверами, что, во-первых, позволяет избежать ограничений объема единичных устройств, и, во-вторых, разнести нагрузку.

Подобный концепт обеспечивает наилучшую масштабируемость и производительность, за что Lustre снискала немалую популярность в научном мире (Lustre используется в 30 из top 50 суперкомпьютеров). Однако для бизнеса это решение не очень подходит, потому что требует солидного количества аппаратуры для работы, а значит - излишне громоздко для типичных бизнес-задач, вроде кластера СУБД. Для подобных задач остроумные люди придумали симметричные разделяемые (кластерные) файловые системы с доступом к устройству хранения на блочном уровне.

Симметричные ФС с разделяемым диском (GFS, GFS2...)


Подобные файловые системы характеризуются отсутствием функционального разделения узлов с одной стороны, и достаточно высокой производительностью - с другой. Принцип действия данных систем следующий:
  • Могут использоваться любые протоколы доступа к разделяемому блочному устройству, будь то стандартные (FC, iSCSI) или софтверные линуксоспецифичные (GNBD). Естественно, каждый из методов обладает своими преимуществами и недостатками.
  • Должны использоваться кластерные службы, в частности, cman (задача - обеспечение функционирования распределенного менеджера блокировок), fence (задача - "отсечение" некорректно работающих узлов от данных и восстановление).
  • Для управления хранилищем данных обычно используется CLVM, кластерный вариант управления логическими томами от Red Hat. Принцип действия, за исключением блокировок, тот же самый, что был описан в предыдущих постах для LVM.
  • Используется журналирование метаданных и данных, что обеспечивает, соответственно, целостность файловой системы/даных.
Общий алгоритм работы выглядит следующим образом:
  • Каждый узел занимает свой индивидуальный журнал.
  • Информация о блокировках распределена между узлами. В нормальном положении все узлы в курсе всех блокировок.
  • Узлы открывают файлы и работают с данными. При этом клиенты осуществляют прямой параллельный доступ к ФС, работая с данными на блочном уровне.
  • ФС поддерживает изменение размеров (только в большую сторону) без отключения.
В случае отказа одного из услов происходит горячее восстановление по следующему алгоритму:
  1. Узел "убивается" (fence). Обычно это осуществляется физическим отключением питания, используя какие-либо сетевые устройства (APC, HP iLO,...).
  2. Один из узлов в кластере завершает свои операции и освобождает свой журнал, забирая себе журнал сбойного узла.
  3. Операции по журналу сбойного узла откатываются/завершаются и система продолжает функционировать как ни в чем ни бывало.
При всем при этом производительность решения с параллельной симметричной блочной ФС выше, чем у NFS, не требуя при этом того колчества доп. аппаратуры, которое используется в Lustre. GFS давно стала привычной технологией для решения бизнес-задач, вроде организации кластеров СУБД, благодаря некоторым расширениям POSIX, которые предоставляет GFS, как-то:
  • Direct I/O - синхронный режим записи на диск для определенных файлов.
  • Freeze/Unfreeze - возможность приостановить работу с FS (корректно "подвесив" системные вызовы на прочих узлав) с одного узла (например, для нужд обслуживания).
  • CDPN (Context Depending Path Names - контекстно-зависимые пути к файлам), позволяющий хранить данные, специфичные для узла, на общей файловой системе.
К сожалению, первая версия GFS не была лишена недостатков. К числу их можно отнести:
  1. Хранение журналов "рядом" с файловой системой, а не на ней. Это приводило к ситуации, в которой нельзя было увеличить количество журналов, не уменьшив объем файловой системы (что, напомним, делать онлайн нельзя), либо не увеличив размер логического тома.
  2. Отсутствие поддержки хранения информации SELinux (контекстов файлов).
  3. Падение производительности при работе с большим количеством мелких файлов.
Эти недостатки были исправлены в этом году с выпуском версии GFS2.

Резюме.


В Linux наблюдается огромное разнообразие (многие считают его избытком) поддерживаемых файловых систем, локальных и сетевых. Причем в отношении сетевых ФС в полной мере справедливо правило UNIX: каждый инструмент решает свою четко очерченную задачу. В этом плане сетевые файловые системы (NFS) удобно использовать для небольшого количества клиентов и интенсивного ввода/вывода, GFS - для интенсивных задач ввода/вывода в масштабах типичного бизнес-кластера, а Lustre - для MPP-систем.