Подписаться
Читать в телеграм
Популярные почтовые клиенты, браузеры, архиваторы, текстовые и графические редакторы не требуют с нас платы. Но мы уже привыкли доверять их надежности. Как правило, они распространяются бесплатно и предоставляются на условиях «как есть». Правообладатель не несет гарантийных обязательств, а все риски, связанные с качеством и производительностью, а также расходы по техническому обслуживанию принимает на себя эксплуатирующая сторона. Для личного использования мы зачастую готовы принять их, так как необходимость обращаться в службу поддержки возникает достаточно редко, а возможность избежать лишних расходов никогда не бывает лишней.
Совсем иная ситуация складывалась при разработке аутсорсинговых и сервисных решений или услуг. С одной стороны, правообладатель программного обеспечения всегда требовал покупки лицензий и дальнейшей поддержки. Но есть еще одна сторона — закрытость программного кода платных решений предполагает, что все исправления в ПО будут вноситься только вендорской поддержкой, а для этого пользователю нужно сначала доказать наличие проблемы (желательно, чтобы она еще и воспроизводилась всегда). А потом ждать, когда будет выпущено соответствующее обновление. Конечно, для всех критичных продуктивных систем уже стали привычными предварительное тестирование и backup систем перед обновлений и установкой патчей. Нередко в результате тестирования выявляются новые проблемы, блокирующие внесение изменений на продуктивных системах.
Так как интеграторы обычно оказывают комплексные услуги, включающие в том числе и использование ПО, стоимость последнего влияет на стоимость самой услуги. Неизбежная необходимость тестирования любых изменений, а также растущая потребность в снижении стоимости услуг в настоящее время становятся предпосылками к использованию открытого ПО при разработке аутсорсинговых услуг. В этой статье мы бы хотели рассказать о свободном программном обеспечении, которое удалось успешно интегрировать в предоставляемые услуги.
В этом году наши специалисты в рамках одного проекта успешно провели тестирование и внедрение свободно распространяемого гипервизора. К слову, в течение нескольких последних лет наша компания использовала решение с платной поддержкой уровня Enterprise.
Основными критериями его выбора были платная поддержка вендора и его присутствие в списках совместимости баз данных и приложений, обычно использующихся в среде виртуализации. Несмотря на все красоту «на бумаге», мы столкнулись с проблемами практически с самого начала.
Первая проблема, которую нам удалось выявить, была связана с производительностью сетевых драйверов. Нас это, мягко говоря, удивило. Казалось, что для среды виртуализации драйверы для самых распространенных операционных систем должны быть в первую очередь протестированы и работать безукоризненно. Платная поддержка, безусловно, помогла решить проблему. Всего через год вышли необходимые обновления! Все бы ничего, но за год наша ферма виртуализации немного подросла, поэтому стали проявляться новые проблемы.
На этот раз уже не с производительностью, а с надежностью. Живая миграция виртуальных машин между хостами гипервизора работала, но не всегда. Виртуальные машины либо переезжали, либо зависали или паниковали. Показатели успешности выполнения стандартной процедуры, равные 50%, не могли радовать.
Но это были не все сюрпризы. Дальше мы обнаружили, что штатная перезагрузка виртуальной машины может, оказывается, приводить к перезагрузке хоста виртуализации. Причем не того, на котором она работала, а того, на котором она пыталась стартовать.
Множество кейсов и предоставление всевозможных логов не привели к решению проблемы. Дампы памяти не хотели собираться, несмотря на то что были корректно настроены. А если и собирались, поддержка не находила там причин проблем.
К концу прошлого года необходимость появления альтернативного решения стала очевидна, и напротив, платная вендорская поддержка теперь не является необходимым условием. После тщательного изучения решений, представленных на рынке, мы решили протестировать две Open Source платформы виртуализации: XenServer и oVirt. Согласно документации, у них были похожие технические характеристики, а маркетинговые материалы обещали сверхнадежность и решение всех задач.
Составляя программу и методику испытаний, мы предусмотрели необходимость тестировать выбранные платформы на наличие тех проблем, которые были выявлены в процессе эксплуатации текущего решения.
При тестировании oVirt сходу наткнулись на баг, который сделал нам петлю в сети. Неприятно, конечно, но мы решили продолжать тестирование, попутно создав кейс в Red Hat Bugzilla. Нас особенно удивило, что ответ по данной проблеме мы получили в течение 2 часов. В последнем релизе, который вышел в день инсталяции тестовой среды, все было уже исправлено. После общения с платной техподдержкой такая оперативность удивила.
Тестирование производительности обеих платформ виртуализации показало хорошие результаты. Все отработали отлично. Функциональное тестирование также особых проблем не выявило – все настраивалось согласно документации. А вот нагрузочное тестирование выявило некоторые проблемы, причем только в XenServer.
Удалось не только воспроизвести зависание загруженной виртуальной машины при ее миграции, но и потерю данных одного из ее дисков. Проблемы наблюдались не каждый раз, но достаточно часто, чтобы опасаться того, что в промышленной эксплуатации такое поведение может приводить к простою. К чести XenServer надо признать, что проблема была достаточно быстро решена – нам удалось найти ее описание и решение уже через пару недель.
В свою очередь oVirt нагрузить так, чтобы он повел себя нештатно или чтобы это привело к потере данных, временной или полной остановке сервиса, так и не удалось. Так как в данном тестировании вопрос надежности решения был приоритетным, наш выбор был очевиден.
За 6 месяцев эксплуатации выбранного решения для средств тестирования и разработки, аварийных ситуаций с виртуальными машинами не зафиксировано. Правда, за время тестовой эксплуатации нам удалось обнаружить еще одну проблему, не влияющую на доступность сервисов. Не всегда корректно работали назначения прав при работе с группами пользователей. В течение 2 недель мы получили от разработчиков подтверждение проблемы и ответ, что срок устранения — ближайший релиз. Такой оперативности и стабильности от гипервизора с платной Enterprise-поддержкой нам получать не удавалось.
За время тестирования наша команда тестирования овладела необходимыми навыками поддержки выбранного решения, а за период тестовой эксплуатации закрепила их. Наработанные компетенции и открытость исходного кода позволяют нам самостоятельно устранить часть проблем или разрабатывать недостающий функционал.
Второй практический кейс, о котором я хотел бы рассказать, касается программного обеспечения, позволяющего осуществлять мониторинг. Немного предыстории… Одной из самых востребованных услуг нашего аутсорсинга является мониторинг. Услуга комплексная — ее невозможно предоставлять без проработанных моделей здоровья, отлаженных процессов обработки инцидентов и взаимодействия с заказчиками. Программное обеспечение, с помощью которого осуществляется мониторинг, кроме получения данных с объектов мониторинга, должно иметь возможность хранения истории, а также интеграции со смежными системами. В 2008 г. нашей компанией в качестве системы мониторинга было выбрано платное решение одного из лидеров рынка. Опыта его администрирования и поддержки было немного, поэтому стандартная архитектура агентского мониторинга с подключаемыми модулями для начала вполне устраивала. За отдельную плату к стандартному модулю мониторинга операционной системы можно было добавить, например, модули для мониторинга базы данных, специфического hardware сервера или массива.
Такая архитектура полностью оправдывала себя для небольшого окружения, включающего несколько десятков хостов. Услуга оказалась востребованной: через пару лет десяток превратился в сотни серверов, десятки массивов, множество разнообразного оборудования сети передачи и хранения данных. А кроме этого, множество шишек, набитых в процессе администрирования. К счастью, к решению части проблем в системе мониторинга нам удавалось привлекать вендора. Самостоятельно вносить изменения и диагностировать закрытые модули мониторинга возможности не было, но нам разрешали добавлять функционал своими модулями. Часть из них были разработаны «с нуля», некоторые пришлось переписывать под текущие потребности заказчиков. Параллельно велась работа по повышению эффективности процесса обработки инцидентов и модернизации моделей здоровья, что позволяло поддерживать все больше оборудования.
В 2014 г. появилось дополнительное требование к услуге мониторинга: необходимо было снизить ее стоимость без ущерба функциональности и надежности. Как оказалось, больше половины конечной стоимости услуги составляли лицензии на агентов системы мониторинга и поддержка производителя. Проведенное исследование показало, что для многих наших заказчиков важны своевременное получение информации от системы мониторинга и ее стоимость, а не средства реализации, поэтому было принято решение поискать альтернативные варианты.
Тестирование Zabbix как альтернативы платному решению началось еще в 2013 г. в рамках пилотного проекта. На тот момент перед командой тестирования стояла задача по реализации существующих моделей здоровья на новой системе мониторинга и ее интеграции со смежными системами. На адаптацию и тестирование новой системы потребовалось порядка 4 месяцев. Полученное решение удовлетворяло всем требованиям, не уступая платному решению. Доступность и отказоустойчивость как нового, так и старого решения обеспечивалась архитектурой инфраструктурных сервисов. Модули, ранее разработанные для платного решения, были перенесены без потери функциональности. По имеющимся моделям здоровья были сформированы эталонные шаблоны. При этом для эксплуатирующего подразделения упростился процесс диагностики проблем, так как исходный код стал доступен для изучения.
Поскольку функциональность и надежность новой и старой систем мониторинга были аналогичны, а процесс обработки инцидентов и взаимодействия с заказчиками не изменился, для конечных пользователей услуги была заметна только разница в стоимости. Новая реинкарнация старой услуги стала так востребована, что за 2 года число объектов мониторинга во много раз выросло… Старым решением продолжают пользоваться только 10% наших клиентов.
Использование открытого ПО как альтернативы платным продуктам при разработке собственного решения может снизить его конечную стоимость. Поддержка с помощью community может стать реальной заменой платной поддержке, если проект «живой» и развивается разработчиками. Наличие собственных специалистов ПО, которые разбираются в его работе вплоть до исходно кода, обязательно. Документация, как правило, не успевает за разработкой, а это может привести к проблемам при поддержке сложного freeware. На это стоит обратить особое внимание при выборе ПО.
Конечно, разработчик такого ПО не предоставит вам гарантий его работоспособности, но вам удастся разделить с ним эксплуатационные риски. Для этого при разработке проектного решения необходимо учесть все возможные сценарии отказа используемого продукта. Незапланированных простоев поможет избежать предварительное тестирование любых изменений перед применением их на продуктивных средах, но это верная практика и для платных решений. Открытость исходного кода упрощает интеграцию со смежными системами, а также при необходимости позволяет внести необходимые функциональные изменения или исправления.
Использовать freeware целесообразно, если выгода очевидна, а для снижения сопутствующих рисков всегда можно найти решение.
