Я (справа) пытаюсь объяснять крупному бизнесу, что такое опенсорс, а мой коллега слева придает опенсорсным решениям душевности.

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

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

Начну не с этого. Начну с того, что напомню, что ещё 17 декабря 2010 г в распоряжении №2299-р В. Путин подписал план перехода федеральных органов власти и бюджетных учреждений на использование свободного ПО. Сейчас расскажу, как мы по плану уже живём в мире русского опенсорса.

— Что было в старом приказе?
В декабре 2010 был установлен план перехода на открытое ПО для ряда госкомпаний. Пункты следующие – в 2012 точные требования к квалификации от Минкомсвязи и Миздравсоцразвития РФ, изменения в программе для школ и университетов (+Минобрнауки РФ), с 2013 по 2015 – конкретные рекомендации по требованиям к ПО накатываются на госкомпании. Параллельно идёт техническая часть: в 2011 – формирование пакета для решения типовых задач и начало работы поддержки, в середине 2012 – создание единого репозитория для федеральных органов. Конец 2012 – первые тестовые внедрения. 2014 – основной запуск. Вот по этой ссылке можно посмотреть весь план.

— И что, правда, накатили?
Не так, чтобы очень получилось – многие пункты носили рекомендательный характер, наверняка были сложности между общением ведомств и т.п. В общем, что-то я не вижу повсеместного русского опенсорса, но кое-какие подвижки действительно были. Сейчас происходит другая важная вещь – 27 января 2015 было распоряжение Правительства о «формировании благоприятных условий для разработки отечественного конкурентоспособного программного обеспечения». Это план импортозамещения и прямого развёртывания у нас независимого центра разработки открытого ПО для госкомпаний. Звучит оптимистично, но точно что это и как будет понятно через пару месяцев.

— В чём проблема делать всё сейчас?
В том, что план импортозамещения предполагает разработку русского ПО. А что подпадает под это определение – пока сложно сказать. Например, непонятно, попадает ли туда ПО Параллелс — и даже непонятно, подпадает ли туда творение Больгена. Как только формулировки появятся, очевидно, почти все коммерческие игроки постараются им соответствовать.

Надеюсь, со скучной частью покончили. Давайте уже FAQ!

По почтовому серверу

— На что заменить, чтобы было похоже на MS по интерфейсу и поддержке?
Обычно нужны задачи, календари, встречи и прочее привычное. В общем, всё, что требуется для полноценной офисной работы. Плюс это обычно переход, то есть ещё нужно перетащить все данные пользователей и сохранить существующую почту. Особой популярностью пользуются:
• Zimbra Collaboration, функционал которого расширяется при помощи зимлетов (zimlets)
• И Zarafa

— В чём будут после работать пользователи?
После миграции, скорее всего, большинство пользователей продолжит работать в Microsoft Outlook (синхронизация через MAPI). Фактически пользователи в этом случае не замечают замену почтового сервера.

— А кто работал через браузер?
Тем, кто работал через Outlook Web Access, придётся осваивать новый интерфейс. Им нужно будет лишь привыкнуть к Zimbra Web Client или Zarafa WebApp. Вот примерный вид:


Интерфейс Zimbra Web Client


Интерфейс Zarafa WebApp

— Что по архитектуре?
Архитектура решений на уровне пользователя крайне похожа на Exchange. А вот «бэкэнд» отличается. Для обеспечения отказоустойчивости решения также имею в своем составе серверы разных ролей, но дублирование-репликация БД организуется иначе. Например, можно использовать ту же виртуализацию СХД, GlusterFS или Ceph.

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

По офисному ПО

Офис был и остаётся одной из главных статей ИТ-затрат.

— В чём сложность перехода?
Основная сложность при переходе на Опенофис (и ему подобные) заключается в разности форматов документов MS (docx) и ODF — речь идёт о настройке открытых решений для корректной работы с проприетарными форматами. Часть функций MS доделал по-своему, и они в стандарте отсутствуют. Неправильный путь перехода — поменять офисный пакет и начать фиксить баги которые возникают. Правильный – сначала проработать переход на использование ODF. То есть поменять формат сохранения документов, пока у вас ещё MS-решение. По большому счету нужно выявить те функции, которых нет в ODF, и исключить их из использования (как правило, они реализованы иначе). Путей несколько, от простого дообучения пользователей до разработки шаблонов, в которых будут выставлены необходимые параметры и кастомизации самого офисного пакета.

— Что с макросами?
Макросы придется переделать.

— Что дальше?
После того как пользователи начнут работать в таком режиме через какое то время можно будет без особых сложностей заменять и сам офисный пакет. Со старыми документами в каждом случае придется придумывать свой способ. Можно оставить несколько MS Office для конвертации особо сложных документов – или можем организовать массовую конвертацию архива в PDF. Вопрос в том, для чего нужен старый документ (и не дай Бог, это какой-нибудь сложный инженерный документ, который нужно часто править).

По виртуализации и терминальному доступу

— Что ставить по виртуализации на инфраструктуру средней компании?
Наиболее просты для внедрения oVirt и Proxmox. Архитектурно эти продукты не сильно отличаются от типовых коммерческих, но есть отличия в масштабировании. Proxmox, например, не предназначен для больших инсталляций. Мониторинг делается через Zabbix или Nagios. Для отчетности, графиков загрузки и тд, можно использовать, например, Jasper, для интеграции с которым в oVirt есть соответствующий адаптер и уже существует набор преднастроенных отчетов. Естественно мы по требованиям его всегда готовы расширять и кастомизировать для конкретного заказчика. Proxmox очень хорош до 16 железных серверов, а oVirt до сотни.

— На что можно заменить терминальные сервисы в принципе?
Терминальные решения, в том или ином виде есть у многих. Часто это решения от всем известной компании на букву С. Но в последнее время они стали крайне дороги и все ищут альтернативу. Практически по всем пунктам решение подобрать можно. Хотя надо честно признаться, что пока, по фичам с лидерами коммерческих решений сравниться будет трудно. Но опять-таки, на все 100% часто эти продукты и не используются. Из тех что мы можем рекомендовать решение Ulteo — это открытое ПО с платной и бесплатной версиями. Есть еще платный коммерческий продукт Thinlinc.

— Что ещё надо знать про переход на *nix после Win?
Архитектурно продукты имеют механизмы разделения на роли и обеспечения отказоустойчивости аналогично остальным. Могут кстати использовать и Windows серверы в качестве терминальных, то есть сам брокер будет работать на линуксе, управлять фермой Linux-терминалов, и фермой windows терминалов. С точки зрения используемого канала на пользователя, используется протокол схожий с RDP так что и требования аналогичные.

— Что делать с Win-приложениями?
У многих заказчиков остаются приложения которые они пока не могут портировать на линукс платформу. И поэтому много вопросов что делать с ними при миграции терминальных сервисов. Есть вариант использования платного Wine: Коллеги поддерживают достаточно большое количество именно офисного и бухгалтерского ПО. Запуск Win-приклада на Wine часто требуется отладка и донастройки, но, как правило, обычно есть нативные аналоги. При наличии исходников своего самописного ПО мы можем портировать за достаточно короткий срок.

— Можно оставить Win-машины и поменять только основное решение?
Да. Частый случай перехода – первый год на терминалах Windows с заменой самого терминального решения. Это как минимум существенно снижает вложения в него.

— Что по сертификации?
Важно уточнить, есть ли защищаемая информация особого рода: иногда требуется Alt linux, Rosa linux, Astra linux из-за сертификации ФСТЭК, ФСБ, Минобороны. Если сертификация не нужна, то можно использовать CentOS, OpenSUSE, или их платные варианты, Redhat Desktop linux, Suse Enterprise Desktop linux. Мы рекомендуем то, что уже видели на практике, поэтому фактический список вариантов наверняка шире. По интерфейсу большая часть этих систем близка к окружению Windows, путаться будет сложно.

Служба каталога

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

— Как заменить и не потерять функциональность групповых политик?
Основной подход для решения этой задачи: LDAP + система управления Puppet или chef.
Система управления позволит как раз заменить групповые политики в части скриптов, настроек и прочих вещей которые они делают.

— Что нужно знать про Samba и OpenLDAP?
У всех наверное на слуху решение для Linux, Samba версии 4.х., которое может работать в качестве контроллера домена, поддерживая схемы леса доменов уровней Windows 2003, 2003 R2, 2008, 2008 R2. OpenLDAP, работающий в связке с файловым сервером Samba, может быть заменой Microsoft Active Directory и файловых серверов под Windows. OpenLDAP — открытая кросс-платформенная реализация протокола LDAP, распространяемая под собственной свободной лицензией — OpenLDAP Public License.

— А как быть с групповыми политиками?
Для Win-админов есть сложности с групповыми политиками, поэтому мы рекомендуем FreeIPA + Puppet или Chef (LDAP-каталог и системы управления).

— Можно ли авторизоваться в домене AD Linux-машиной?
Для аутентификации и авторизации Linux в домене Active Directory использование дополнительных средств не требуется. Необходимый функционал реализован в штатных средствах.

— Ну а все таки, что больше всего похоже AD?
Скорее, FreeIPA — открытый проект, обеспечивающий централизованную проверку подлинности, сохраняя данные пользователей, групп, хостов и других объектов, необходимых для управления компьютерной сети. FreeIPA через веб-интерфейс и/или с помощью командной строки позволяет централизовано управлять защищенной инфраструктурой на предприятия и доступными ресурсами. Начиная с версии 3.0.0, FreeIPA также использует Samba для интеграции с AD методом установки доверительных отношений. Умеет управлять такими вещами как 389 Directory Server, MIT Kerberos, DogTag, DHCP, DNS, NTP.

Балансировка нагрузки

Дело в том, что «железный» именитый балансировщик может стоить как чугунный мост. Но в опенсорсе не всё так однозначно — каждое решение различается в зависимости от уровня OSI, на котором оно может осуществлять балансировку нагрузки: канальном, сетевом, транспортном или прикладном. Очень много ограничений накладывает имеющийся парк оборудования. В общем, здесь квалификация внедренца очень важна.

— К чему стоит присмотреться?
• Есть такой кусок ядра — Linux Virtual Server (подключающий IPVS), реализующие коммутация пакетов на транспортном уровне (L4). Всё то, что работает на этом уровне, так или иначе действует в плотной связке с LVS. Пример решения — Keepalived — ПО для балансировки и обеспечения высокой доступности решений на базе ОС семейства Linux. При помощи данного решения можно решить задачи по созданию отказоустойчивого балансировка нагрузки на транспортном уровне (L4); отказоустойчивого балансировка нагрузки на связке с, к примеру, С другой стороны, те же Haproxy или Nginx работают на уровне приложений (L7). Балансировка нагрузки на уровне сетевых пакетов требует меньших вычислительных затрат и обеспечивает лучшую масштабируемость.
• HAProxy — балансировщик нагрузки и прокси-сервер уровня приложений (L7), подкупающий своей производительностью;
• BalanceNG — балансировщик, работающий на канальном уровне (L2), с хорошей функциональностью и простотой в настройках;
• Pound — узконаправленный инструмент, представляющий собой обратный прокси-сервер и балансировщик нагрузки для HTTP и HTTPS (L7);
• Crossroads — обеспечивает балансировку нагрузки к любым TCP-сервисам, и предоставляет возмность гибкой настройки.
• Zen Load Balancer — поддерживается балансировка на траспортном уровне (L4) для протоколов TCP, UDP и на уровне приложений (L7) для HTTP/HTTPS. Основной особенностью является наличие веб-интерфейса.
• Keepalived — простой и надежный балансировщик 4-го уровня.
• А ещё мы умеем nginx и apache как балансировщики 7-го уровня, если нужен SSL offload.
• А вообще то мы можем сделать Trusted TLS на ГОСТовом шифровании. Особенно интересно это для портальных решений, которые выставлены в интернет.

— Какие задачи чаще всего решаются?
Например, организовать отказоустойчивое решение и обеспечить балансировку нагрузки
? по любым портам и на любые порты;
? поддержка менизмов server NAT и client NAT;
? проверка состояния узлов кластера;
? возможность запоминать сессию;
? возможность подключаться к сетевому оборудованию через TRUNK и организовывать виртуальные адреса в разных VLAN.

Существует несколько решений, алгоритмы и методы которых уже описаны в статье «Балансировка нагрузки: основные алгоритмы и методы», и некоторые мы можем рекомендовать как проверенные.

Бекап

Про бекап нас почти не спрашивают, хотя тема очень интересная. Область защиты данных – пожалуй, последнее, что заказчики готовы доверять «непонятному» открытому ПО. Но вот отдельно стоит продукт от Bacula, его любят и ценят, кто пробовал. Остальные продукты из-за скудности функционала работы с базами enterprise-ПО могут только защищать небольшие инфраструктуры с файловыми данными.

Общие вопросы

— Что опаснее для безопасности данных – открытое ПО или коммерческий продукт?
В целом – одинаково. В закрытое ПО вы не можете заглянуть и разобраться, а открытый продукт плох дырявостью на первых этапах. Когда вокруг продукта собирается серьёзное коммьюнити, открытое ПО по своим свойствам надёжности и функциональности прямо конкурирует с коммерческими решениями.

— Как оценивать эффективность внедрения открытого ПО?
Капитальных затрат на лицензии нет. Есть затраты на интеграцию и доработку, они почти такие же, как на коммерческом ПО. Для инфраструктурных решений обычно всё куда дешевле, а в прикладе, случается иногда (редко) дороже за счёт дополнительной разработки. Вместо вендора с поддержкой почти всегда есть компания, которая делает то же самое для определённого проекта, плюс можно поставить на поддержку любую другую команду. Проблема в кадрах – их, как правило, нужно обучать, пока ощущается дефицит грамотных специалистов по открытому ПО. Способных носить галстук.

— Чем отличается СПО-внедрение от коммерческого?
На пальцах – оценка для коммерческого софта такая: «Так, это сюда влезает, это сюда не влезает, а в это вот это дорогое почти идеально подходит — с вас миллион». А для открытого ПО «Так, это сюда влезает, это сюда не влезает, а в это тут мы один модуль просто допишем». Получается дешевле и всё встаёт как надо.

— Что с правами?
С учётом, что мы не разрабатываем инфраструктурные решения, права на нашу разработку передаются заказчику. Заказчик может делать с ними что угодно, хоть выкладывать в открытый доступ. Но так делают не все.

— Каковы отношения с коммьюнити?
Мы интегратор, а не разработчик, поэтому обратно отдаём мало. Тем не менее, тот же Alt Linux получил от нас чуть ли не половину своего годового бюджета за поддержку одного из проектов. Передаём обратную связь, помогаем править связки совместимости между крупными вендорами и разработчиками открытого ПО на интеграциях (как правило, апдейтятся в основной ветке потом обе стороны). Самое важное – знаем, как выглядит большой проект и в чём проблемы. Разработчики СПО зачастую не имеет понимания больших решений. Настоящий энтерпрайз — это страшно из-за адского геморроя по куче разных мелочей. Такие проекты не любят и их заслуженно боятся. Собственно, это нормально, задача разработчика — продукт, а не конечное внедрение. А вот применение за нами – и тут целое море сюрпризов.

— Где про мифы опенсорса?
А вот же. Тут про поддержку и многое другое, плюс список решений.

— Что сейчас поменялось?
Всё. Поменялось отношение к СПО — раньше нос воротили, а теперь уже на этапе концепции развития ИТ компании добавляют пункт про импортозамещение. Открытое ПО приоритезируется. Некоторые отрасли, отраслевые НИИ как раз наоборот, разрабатывают свои собственные и инфраструктурные решения на базе СПО и прикладуху. Планируют использовать повсеместно в рамках своих отраслевых компаний. Заказчики лучше разбираются в открытом ПО. Чаще идёт запрос на варианты реализации, цены, потом у нас появляется руководитель ИТ, с которым обсуждаются CAPEX и OPEX, а потом матеарилизуется админ, с которым мой коллега (см. рис. 1) решает технические вопросы. Но нас, конечно, в отделе не двое, а гораздо больше.

Остались вопросы?

Если у вас остались вопросы, приходите к нам на вебинар по вендорозамещению, 29 апреля. Детали и форма регистрации тут.
Если не получится попасть, моя почта — AlBelyaev@croc.ru и личка доступны для вопросов.