Облако ЦОДов, или Сон разума

На одном из важных НТС не так давно я обнаружил в выступлении главного конструктора информационных систем одного из уважаемых ведомств потрясшую меня метафору — он описал облачную инфраструктуру как совокупность «облака ЦОДов, облака „серверов доступа“ и подключенных к ним сервисов, таких, как документооборот, безопасность, почта» и других такого же уровня. «Облако ЦОДов» меня потрясло. Я понял, что нужен рассказ, даже не статья, поясняющий основы предметной области, даже не вдаваясь в конкретику реализаций тех или иных принципов.

Ниже я попробую это сделать.

За последние десятилетия мощность компьютеров выросла на многие порядки, человек же, хотя, возможно, и стал умнее, но точно в меньшей степени. Чаще — умнее не стал, хотя человечество в целом значительно продвинулось вперед. И, работая на персональных компьютерах, человек использует их возможности совсем незначительно, и чем дальше, тем относительно меньше. Быстродействие мозга не изменилось, оно остается, как и много лет назад, около 50 операций в секунду. Тактовая частота компьютеров измеряется гигагерцами. Все, что может человек — это загрузить компьютер на единицы процентов.

Мы платим за 100 процентов ресурсов компьютера, а используем, например, 2 процента. В 50 раз переплачиваем. Жалко.

Конечно, если человек будет платить в 5 раз меньше, то ему это выгодно. И если ресурсы компьютера разделить на 20 человек, и каждый будет платить за 10 процентов ресурсов, то и владелец компьютера останется в ощутимой выгоде, тем более что на оплату энергетики будет уходить в разы меньше средств. Вот такие рассуждения и явились причиной появления систем виртуализации.

На маленьком компьютере можно поддерживать немного виртуальных машин. Очевидно, что чем мощнее компьютер, тем больше виртуальных машин может на нем работать, и тем эффективнее будет виртуализация. Конечно, в том случае, если большая часть виртуальных машин будет использоваться. Мало их создать, нужно, чтобы они были востребованы.

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

Доступ к ВМ для клиента можно организовывать по-разному. Например, если на ВМ установить терминальный сервер, то клиенты могут получать доступ в терминальном режиме. WEB-сервер обеспечит WEB-доступ.

Чтобы получить на ЦОДе в свое распоряжение ВМ, нужно понять, какими именно ресурсами эта машина должна располагать, и попросить администратора создать именно такую ВМ. Однажды созданная, ВМ останется именно такой до тех пор, пока не будет изменена или удалена администратором. Другими словами, мы наблюдаем статическое распределение ресурсов. Пользователь знает, где именно находится его ВМ, и что она из себя представляет.

Несколько ЦОДов иногда объединяются одним механизмом управления. Теперь ВМ могут размещаться не только на разных физических серверах, но и на разных ЦОДах. Но до сих пор пользователь при желании может точно установить, где находится его конкретная виртуальная машина.

Так может продолжаться до тех пор, пока ресурсов группы ЦОД хватает для размещения всех требуемых виртуальных машин. Рано или поздно все ресурсы ЦОД окажутся занятыми, и тогда придется «уплотняться».

Заказывая себе ВМ, мало кто удержится от того, чтобы заказать ее «на вырост». Конечно, за заказанные ресурсы нужно платить, но не так уж и много, и, значит, лучше взять «про запас». В результате, хотя эффективность использования ресурсов в ЦОД намного выше, чем при использовании ПЭВМ, все-таки оптимальным такое использование не назовешь. Каждый взял себе по 20-30% запаса ресурсов, значит, свободные ресурсы есть, а использовать их нельзя. Неэкономно получается.

Вот только здесь появляется потребность в том, что отличает «облако» от виртуализации оборудования. Это — динамическое распределение (выделение) ресурсов. «Облако» характеризуется виртуализацией оборудования, виртуализацией ОС, виртуализацией приложений и динамическим распределением ресурсов.

При работе «в облаке» ВМ может размещаться на любой памяти, исполняться на любом сервере любого ЦОД, входящего в состав облачной инфраструктуры. Говорят, что ВМ «мигрируют» между ЦОД. Решение о миграции ВМ принимает «планировщик», исходя из различных соображений, например, из логики равномерности загрузки ЦОД, цены ресурсов, просто наличия свободных ресурсов, и других. Не принимается во внимание только (!) уровень конфиденциальности информации, обрабатываемой в ВМ.

Таким образом, облачные технологии начинаются тогда, когда исчерпаны все ресурсы ЦОДов, предоставляющих пользователям виртуализированное оборудование на основе использования систем виртуализации. Облачная инфраструктура — это взаимодействующие на основе специализированного «планировщика» ЦОДы, средства доступа и клиентские машины. Защищенная облачная инфраструктура — это защищенные серверы, защищенные ЦОД, защищенные ВМ, защищенный доступ (WEB и/или терминальный), и, наконец, защищенный планировщик, планирующий миграцию ВМ из соображение, в том числе, защищенности информационных ресурсов.

Облако — это все вместе. Не бывает «облака ЦОДов», не бывает «облака серверов доступа», не бывает «облака сервисов», бывает облачная инфраструктура в целом и облачные сервисы, скрывающие от пользователя всю эту сложную механику и предоставляющие пользователю доступ к тем ресурсам, которые ему нужны.

Теперь важно — когда же приходит пора переходить на облачную инфраструктуру?

Сначала нужно сделать ЦОД.
Развернуть систему виртуализации оборудования.
Создать виртуальные машины.
Установить на них необходимое ПО.
Разместить на ЦОД информационные ресурсы.
Потом подключить к ВМ пользователей.
Дождаться, когда пользователи начнут использовать 70 — 80 % ресурсов
И только тогда пора думать об облаке.

Здесь опущены вопросы защиты — не надо создавать защиту облака, не научившись защищать виртуальные машины.

Если сегодня вы используете ресурсы ЦОД на 0,5%, и в ближайший год планируете увеличить эту цифру на порядок — не надо думать об облаке. Например, если в Вашем ЦОДе 1000 (тысяча, это немного) физических серверов, и на каждом из них можно поднять 50 (пятьдесят, это немного) виртуальных машин, то 50 000 (пятьдесят тысяч, это много) рабочих мест вполне могут поддерживаться и без облака. Вот если на этом ЦОДе вам нужно обеспечить комфортную работу 100 000 сотрудников, то пора подумать о планировщике, и, соответственно, об организации облачного доступа. Если же в вашей корпорации еще не скоро одновременно будут работать 100 000 пользователей, или если у вас уже есть ЦОДы, которые могут поддержать достаточное количество ВМ — не надо вам создавать корпоративное облако. Используйте в полной мере ЦОД.

Если же, несмотря ни на что, вы все же создаете корпоративное облако, то мотивировать вас может только одно — от публичного облака корпоративное отличается защищенностью. В этом смысле строить незащищенное корпоративное облако - задача, вызывающая удивление и у специалистов, и, думаю, у финансовых контролирующих органов.

Вот дальше поговорим о защите корпоративного облака.

Корпоративное облако можно считать защищенным, если, как минимум:

• обеспечена доверенная среда на компьютерах пользователей;
• защищен доступ пользователей к ВМ (WEB или терминальный);
• обеспечен контролируемый старт серверов ЦОД и ВМ на серверах;
• защищены ресурсы ВМ;
• обеспечена контролируемая миграция ВМ (то есть используется защищенный планировщик).

Эти меры могут сильно расширяться, но без них говорить о защищенности облачной инфраструктуры нельзя.

Опишем кратко возможные варианты и средства защиты.

1. Доверенная среда на компьютерах пользователей может создаваться применением СЗИ НСД (например, это СЗИ НСД семейства «Аккорд» (или аналогичные)) или средства обеспечения доверенного сеанса связи (СОДС) (например, «МАРШ!» или аналогичные);
2. Защищенный доступ пользователей к ВМ можно обеспечить применением VPN в доверенной среде для WEB-доступа, или системой доверенной загрузки терминальных ОС (например, «Центр-Т», основанной на применении СКЗИ «ШИПКА», или «КАМИ-терминал», или других);
3. Контролируемый старт (доверенная загрузка) системы виртуализации обеспечивается специализированными СЗИ НСД (для Vmware это, например, «Аккорд-В.» и аналогичные, для MS HV — «ГиперАккорд»);
4. Защита ВМ осуществляется СЗИ НСД, устанавливаемыми в гостевую ОС (например, «Аккорд-VE» или аналогичные);
5. Системы защиты планировщиков облака еще находятся в разработке, но очевидно, что это вопрос ближайшего будущего.

Каждый из этих пунктов по-отдельности в дальнейшем будет рассмотрен в отдельных статьях под общей серией «Облако ЦОДов».

Автор: Конявский В. А.

Дата публикации: 01.01.2013

Библиографическая ссылка: Конявский В. А. Облако ЦОДов, или Сон разума // Защита информации. Inside. СПб., 2013. № 5. С. 36–37.

---