В рубрику "ИТ-интеграция" | К списку рубрик | К списку авторов | К списку публикаций
При возникновении необходимости экономии у ИТ не так много возможностей. По большому счету все они сводятся к нескольким аспектам:
Как правило, когда речь идет о сокращении издержек, в той или иной степени задействованы все аспекты, перечисленные выше. Например, если стоит задача обеспечения экономии, то ИТ может пересмотреть модель осуществления деятельности аппаратными ресурсами, для ряда функций закупая не импортные высоконадежные сервера известных производителей, а более дешевые отечественные. Правда, в связи с этим придется решить еще одну задачу, а именно обеспечение поддержки работы оборудования. (Затраты на поддержку "зоопарка" могут превышать экономию от перевода части оборудования на другого вендора, поэтому надо предварительно считать.)
Одновременно с этим ИТ может разрабатывать план по экономии на операциях, например посредством автоматизации типовых функций (проще говоря, внедрением еще одной системы автоматизации или доработки уже существующих систем автоматизации). Причем если план не будет планом ради плана, то с большой вероятностью его реализация приведет к определенному экономическому эффекту.
Отдельно стоит остановиться на экономии мощностей. Нет, приложения не становятся менее требовательными к ресурсам. Наоборот, чем дальше, тем более "прожорливыми" до аппаратных ресурсов оказываются разного рода порталы, бизнес-системы, шины данных и т.д. Фактически повышение требований к ресурсам получается своеобразной платой за универсальность и более широкий спектр поддерживаемых функций. Поэтому "в лоб" задача экономии мощностей практически не решаема. А вот если рассмотреть решение от обратного – то очень даже. Речь, как можно догадаться, идет о виртуализации.
Как уже было сказано, один из основных рисков систем виртуализации – это массовый выход из строя виртуальных машин. Нивелируется он по-разному, но в общем ничего сложного. Точнее, возможны варианты. Например, построить второй сервер с зеркалами виртуальных машин или, если позволяют бизнес-требования, делать бэкапы с системой быстрого восстановления. Причем бэкапить можно как машины целиком, так и отдельно массивы данных – все зависит от стоящих задач по обеспечению непрерывности. Следующий риск – это риск неверной оценки мощностей сервера. Он в общем тоже понятный и нивелируется запасом мощности на этапе проектирования сервера. (Обычно для нормальной работы закладывают порядка 20% запаса мощности – как раз чтобы снизить вероятность наступления этого риска.)
Следует отметить, что работа в системе виртуализации в целом предъявляет более серьезные требования как к системному администратору, так и к оборудованию: отказ сервера по любой причине ("человеческой", системной) грозит серьезными последствиями. Что же касается администратора, то его квалификация должна быть достаточна как для администрирования хост-системы, так и для контейнерных (гостевых) операционных систем. Это если говорить о сложностях. А если говорить о перспективах…
В перспективе виртуализация с точки зрения мощностей не единственный способ экономии. Логичным продолжением и развитием идеи виртуализации является виртуализация приложений, или облака. (Если говорить строго, то виртуализация приложений имеет мало общего с виртуализацией серверов, разве что виртуализированное приложение может использовать виртуальную инфраструктуру.) В последнее время очень модно говорить об облачных приложениях как о сервисе, и такого рода услуг действительно много. С одним небольшим, но весомым риском – компрометации данных. И "вес" этого риска таков, что многие компании на корню хоронят саму идею, не желая передавать свои данные третьим лицам (что, кстати, вполне понятно и объяснимо. С другой стороны, облако всеми воспринимается в первую очередь как стороннее приложение). При этом кажущееся противоречие между безопасностью (в части компрометации данных приложения при размещении его на стороне) и удобством решается довольно просто – так называемым частным облаком. То есть облачной инфраструктурой, развернутой в рамках предприятия. При этом такого рода решение обычно удовлетворяет и специалистов по безопасности, и бизнес.
Кстати, кроме прямой экономии, частное облако обладает еще несколькими полезными для бизнеса свойствами. Во-первых, оно разворачивается полностью в инфраструктуре предприятия. Во-вторых, оно полностью управляемо. В-третьих, оно соответствует запросам со стороны бизнеса – в пределах разумного, конечно. В частности, облако можно построить исходя из реальных потребностей бизнеса. То есть задать "на берегу" требования к отказоустойчивости, производительности, защищенности и т.д. – и, следовательно, оценить бюджет решения. Если он окажется избыточен, то попробовать пересмотреть технологию или изменить требования. Вроде бы все просто. Но во что это выливается в жизни?
Облако – это совокупность оборудования и программной части. Причем связка это довольно жесткая: если мы меняем программную часть, то требования к оборудованию также будут меняться. Зачастую, кстати, требования к оборудованию формируются в процессе эксплуатации решения. Это особенно актуально, если программное обеспечение облака пишется "с нуля" под конкретные потребности. В этом случае вычислить на старте, какие потребуются сервера, весьма проблематично. Можно лишь построить гипотезу и исходя из нее проектировать аппаратное обеспечение. По правде говоря, я еще не встречал ни одного случая, когда требования к "железу" закладывали "копейка в копейку". Обычная картина: в зависимости от характера приложения и прогноза нагрузки требования могут существенно возрасти.
Вообще, в этом смысле прогнозирование – довольно непрозрачная операция. Потому что типичное прогнозирование делается методом экспертных оценок, которое при любой квалификации экспертов тяготеет к ошибке. Лично я наблюдал ситуации, при которых реальные потребности вновь разрабатываемого приложения оказались примерно в 5 раз ниже изначально запрошенных. Да, это позволило иметь хороший запас по мощности. Но, с другой стороны, это был замороженный бюджет и неоправданные текущие затраты. Причем адекватных методов расчета нагрузки на вновь проектируемое приложение на старте нет. По-хорошему для более или менее точной оценки необходимо построить макет программы и испытать ее в условиях, эмулирующих реальную деятельность, после чего формировать требования к аппаратной части. Но действительность такова, что эти требования обычно нужны именно на старте процесса по самым разным причинам: от закупки уникального оборудования (некоторое оборудование можно найти только за границей со всеми вытекающими отсюда сроками) до необходимости формировать бюджет. Вот и получается, что метод экспертных оценок чуть ли не "наше все", причем в качестве экспертов выступают сами разработчики и администраторы. Понятно, что выдаваемая ими оценка будет лежать на верхней границе – никто не хочет получить неработающее из-за слишком медленного сервера приложение.
И здесь уместно вспомнить про виртуализацию серверов. Если в компании построена виртуальная инфраструктура, то вопрос с требованиями к аппаратному обеспечению решается чуть проще: приложение может стартовать на минимальной конфигурации, увеличивая ее при необходимости. Тут, правда, есть еще один тонкий момент, который относится уже к приложению. Проектируя облако, особенно облако массового пользования, необходимо заложиться на то, что оно изначально – на уровне приложения и операционной системы – будет поддерживать кластеризацию. В идеальном варианте – в прозрачном режиме, на лету. Нужно еще мощности – добавили сервер в кластер. Появился избыток по мощностям – вывели сервер из кластера или уменьшили параметры виртуальной машины. Это идеальный вариант, который с точки зрения архитектуры позволит обыграть практически любую ситуацию, связанную с плавным изменением нагрузки.
Понятное дело, что такой подход к архитектуре не может застраховать от самой неприятной ситуации, когда нагрузка меняется скачками. Это характерно для приложений массового пользования, режим работы которых зависит от характера работы сотрудников предприятия. Простейший пример: электронная почта. Как правило, ее смотрят утром, соответственно, в этот момент нагрузка может достигать пиковых значений, опускаясь до минимума в обеденный перерыв. И тут, к сожалению, из доступного можно сделать только одно – закладывать требования по максимуму.
Возвращаясь к самому началу статьи, посмотрим, как с помощью хорошо продуманного облака с правильной архитектурой можно оптимизировать затраты и риски. Начнем с оптимизации.
Во-первых, если облако поддерживает кластеризацию, то оно, будучи размещенным в виртуальной инфраструктуре, становится звеном цепочки экономии мощностей и, следовательно, бюджета на текущее обслуживание (а также в ряде случаев – стартового бюджета).
Во-вторых, облако, кластеризованное на разные физические серверы (или на виртуальные серверы, размещенные на разных физических серверах), здорово повышает отказоустойчивость. Особенно если серверам периодически проводят операцию резервного копирования и в запасе имеется сервер, который может быть "поднят" в случае нештатной ситуации с одним из основных серверов.
В-третьих, облако позволяет в какой-то мере экономить на обслуживающем персонале – очевидно, что обслуживать один-два физических сервера гораздо проще. И это если не касаться возможной экономии на времени бизнес-операций. Но это отдельный и довольно непростой разговор, потому что облако, как и любое бизнес-приложение, несет в себе определенные бизнес-идеи, преследует определенные бизнес-цели. И цель "сокращения времени операции" может быть далеко не основной. (Практика показывает, что обычная цель – это упорядочение процесса, и только на втором-третьем месте стоит такой параметр, как сокращение времени операций.) Причем я сознательно не касаюсь того, что облако может быть как сугубо локальное – то есть работать исключительно в рамках предприятия, – так и глобальное – то есть обеспечивать функционирование сотрудника из любой точки, где есть Интернет. По большому счету это определенным образом влияет на экономическую модель опять-таки через время операций, поддержания актуальной информации и т.д. Все это важно и актуально при постановке бизнес-задачи, но ИТ, как правило, смотрит чуть уже – через призму текущего и перспективного ИТ-бюджета, что, кстати, может быть определенной проблемой, и ИТ-директор должен уметь жить в двух измерениях – ИТ и бизнеса. В противном случае возникнет классическая картина взаимного непонимания между ИТ и бизнесом.
Что из этого следует? Вывод, в общем, простой: облака – это перспективная со всех точек зрения модель, которую можно и нужно использовать. Потому что при правильном подходе облако способно решить сразу несколько задач: от экономии до оптимизации.
Опубликовано: Журнал "Системы безопасности" #4, 2014
Посещений: 6438
Автор
| |||
В рубрику "ИТ-интеграция" | К списку рубрик | К списку авторов | К списку публикаций
