Автор: Пользователь скрыл имя, 05 Января 2012 в 11:35, контрольная работа
Первое, что приходит на ум любому человеку при оценке перспектив развития вычислительной техники, — это обязательное уменьшение размеров компьютеров, неуклонное увеличение их быстродействия и объема памяти. Легко прогнозировать, что число выпускаемых ЭВМ будет увеличиваться, а сфера их использования — расширяться. Даже непосвященному человеку сейчас понятно, что будущее вычислительной техники тесно связано с глобальными Сетями.
Очевидно, что перед началом проектов, связанных с выносом тех или иных ИТ-сервисов в «облака», заказчикам следует оценить подобные риски, провести тщательную инвентаризацию приложений (зафиксировав список критически важных для бизнеса), и только затем принимать решения о том, как выстраивать свое «облачное» ИТ-будущее.
Альтернативный интернет-провайдер, находящийся в «горячем резерве», альтернативный поставщик «облачного» решения, прозрачное управление поддержанием архивных копий данных, страхование, жесткие условия ответственности в соглашениях с поставщиками — обязательные элементы безопасности в «облаках».
Задачи
обеспечения целостности
В ближайшем будущем для компаний, нуждающихся в безопасной виртуальной среде, единственным выходом останется создание частной облачной системы, заявили аналитики IDC на проходящей в ноябре 2011 года в Лондоне конференции Virtualisation and Cloud Security Conference. Дело в том, что частные облака, в отличие от публичных или гибридных систем, больше всего похожи на виртуализованные инфраструктуры, которые ИТ-отделы крупных корпораций уже научились реализовывать и над которыми они могут сохранять полный контроль. Недостатки защиты информации в публичных облачных системах представляют серьезную проблему. Большинство инцидентов со взломом происходит именно в публичных облаках, подчеркнул аналитик.
Виртуализация может быть безопасной и соответствующей нормативным требованиям защиты информации, полагают в IDC. Тем не менее, запросы клиентов в сфере безопасности пока еще часто опережают возможности поставщиков. На сегодняшний день, например, в облаках невозможно реализовать сквозное шифрование.
В IDC призвал участников конференции в большей степени уделять внимание частным, а не публичным облачным системам.
Специалисты Gartner придержива
Также аналитики отмечают, что технология облачных вычислений снизит расходы и повысит спрос на новые ИТ-продукты, однако эффект роста от таких технологий проявится только в долгосрочной перспективе.
Выбрать вендора облака - почти как жениться. Обе стороны настроены на лучшее и уверены, что отношения будут долгими и полными любви и взаимопонимания. Но… видимость бывает обманчива, и отношения с вендором могут испортиться. На такой случай и нужен «брачный» контракт (точнее, четкий и исчерпывающий договор), гарантирующий, что обе участвующие стороны знают свои права и обязанности.
CRN обратился к руководителям VAR-компании Progress Software, чтобы получить знание «из первых рук». Мэтт Чиччари, менеджер по маркетингу OpenEdge/SaaS-платформ и внедрению облака, и Майк Ормерод, архитектор облачных и SaaS-решений, поделились своим опытом: какие главные элементы должны присутствовать в «брачном» договоре с вендором облака, чтобы потенциальный клиент мог смело сказать «да».
Руководители Progress Software предупреждают, что решение о внедрении облака может завязнуть в терминах, акронимах и обозначениях. Важно, чтобы потенциальный заказчик выполнил «домашнюю работу» и освоился с терминами, которыми оперируют вендоры, прежде чем вступать на путь переговоров. «Не следует сразу кидаться в новое дело, если вы не понимаете какие-то термины и технологии», - говорит Чиччари. «Прежде всего, нужно понимать, во что вы вступаете», - вторит ему Ормерод.
Недавняя череда облачных отказов чему-то нас научила. Необходимо четкое соглашение об уровне обслуживания (SLA), которое поможет этому союзу был долгим и счастливым. Руководители Progress Software рекомендуют покупателям облачных сервисов внимательно изучить все условия SLA, чтобы знать, кто за что отвечает в разных обстоятельствах. Важно убедиться, что критически важные приложения не будут потом меняться; подписанное SLA защищает не только вашу репутацию, но и имя вендора. «Текст и формулировки SLA - это всё», - говорит Ормерод. «Как во всяком договоре, вы должны иметь абсолютную ясность, кто что делает, когда и как», - добавляет Чиччари.
Не
забывайте: вендоры облака это не
поставщики услуг управления ИТ. Когда
вы вступаете в облако, на вас
лежат те же обязанности, что и
при использовании
Союз двоих - это постоянный труд, и что-то может пойти не так. Важно планировать свои действия на случай неожиданных проблем. Progress Software готова к этому. Прежде чем окунуться в облако, нужно иметь готовый план восстановления после отказов и воссоздания рабочей среды. Высокий уровень готовности - это работа вендора облака, но преодоление отказов - нет, предупреждает Чиччари. «Есть такое заблуждение: я отправляю все свои приложения в облако - и никаких забот», - вторит ему Ормерод. Если союз распался, то неизбежен раздел имущества. Примерно та же ситуация с облаком. Договор вендора должен подробно оговаривать, что происходит с данными заказчика, если он сам или вендор выйдут из бизнеса, если произойдет слияние или покупка одной из сторон, и как долго вендор должен хранить данные клиента. Местонахождение данных и соблюдение регулятивных требований - также важные аспекты перехода в облако, говорит Ормерод.
Это может выглядеть как «неверность», но любой «облачный» договор вендора должен содержать пункт о поддержке различных типов облака с возможностью использовать другие платформы. Следует спрашивать вендоров, обеспечивают ли они поддержку общедоступного, частного облака и гибридной модели, говорит Чиччари. Чтобы отношения были долгими, заказчик должен иметь возможность использовать нескольких вендоров облака одновременно для одного и того же приложения, системы или среды. «Зачем ограничивать себя лишь одним облаком? - говорит он. - А если что-то случится у Amazon, GoGrid или Rackspace?» Заказчики должны задаться вопросом: «Насколько легко мне будет перенести свои приложения от одного вендора к другому?» - добавляет Ормерод. И, наконец, что делать, если отношения не сложились, и обе стороны вынуждены расстаться? Когда медовый месяц прошел, пользователи должны знать, что делать, говорит Чиччари. Что делать, если возникла проблема, как восстановить данные и вновь запустить облачное приложение? А если заказчик просто передумал и больше не хочет использовать облако? Если изменился профиль бизнеса или рынок, и нужно менять стратегию? Договор облачного обслуживания должен предусматривать стратегию выхода, чтобы и вендор, и заказчик могли полюбовно расстаться, избежав неприятных разборок.
Как соотносятся Cloud Computing «облака» и SaaS, и какая между ними разница?
Cloud Computing (облачные вычисления) – это стиль разработки и использования компьютерных вычислений, технология обработки данных, в которой программное обеспечение и динамично масштабируемые ресурсы предоставляются пользователю через Интернет как сервис.
Технология SaaS (Software Services) является составной частью Cloud Computing, одной из трех основных, наряду с IaaS (Infrastructure as a Service) и PaaS (Platform as a Service).
Уровни моделей Cloud Computing:
Теоретически вполне можно построить облако на стандартных серверах (x86) и интеллектуальном программном обеспечении. Объединяем несколько виртуальных устройств и получаем «облако». Но на самом деле это далеко не так. По разным причинам, таким как поддержание адекватной производительности (специализированные ASICs или выделенные аппаратные ресурсы), обеспечение совместимости (установка драйверов для каждой новой платформы x86), или функций контроля (HIPPA, PCI-DSS, ведомственная изоляция, и т. д.), еще далеко не все системные разработчики отказались от использования выделенных аппаратных ресурсов для определенных элементов своих дата-центров. В принципе неизбежность виртуализации некоторых компонентов компьютерной среды очевидна. Поэтому лидеры рынка выпускают соответствующее оборудование. Например, Nexus 1000v, который обеспечивает прозрачность трафика виртуальных машин на уровне сетевой безопасности, с встроенной технологией VN-Link, обеспечивающей мобильность сети. А также виртуальный шлюз безопасности и vWAAS. В одних случаях, клиенты выбирают виртуальные устройства. В других случаях, они предпочитают комбинацию программных и аппаратных ресурсов, например, контрольных точек, представленных Nexus 1010v. Все эти унифицированные сетевые услуги обеспечивают системных разработчиков стандартным набором приемов, позволяющих в случае необходимости совместно использовать программные и аппаратные ресурсы. У многих поставщиков сетевого оборудования идея эластичных ресурсов не полностью реализована. Дело в том, что понятие «эластичных ресурсов» не должно ограничиваться только серверами и системами хранения данных, оно должно распространяться на все «облако», в том числе его сетевые элементы.
Это еще одна область, которую многие связывают только с серверами и системами хранения данных. В течение многих лет, до появления «облака», сеть представляла собой комплексный ресурс, который предоставлял услуги (полоса пропускания, безопасность, сегментация или изоляция, функция QoS, и т. д.) отдельным группам систем. По мере того как сети становились более виртуальными, более автоматизированными, а также росло число их арендаторов, компании, предлагающие решения на этом рынке продолжали расширять интеллектуальную логику своих продуктов, требуемую для функционирования современных «облачных» систем. Эти решения позволяют клиентам развертывать модульные виртуальные системы (например такие, как Vblock и SMT от Cisco).
С одной стороны, это абсолютная правда, в отношении динамического распределения ресурсов и оперативного включения новых виртуальных машин с помощью шаблонов и клонов. Однако, это требует некоторых структурных изменений. Например, при использовании vMotion, Live Migration или XenMotion исходная и конечная точки должны быть в одном логическом домене. А опросы администраторов виртуальных систем показывают, что за месяц им приходится выполнять тысячи миграций виртуальных машин. Итак, в дополнение к этой гибкости им осталось только упразднить традиционное разграничение уровней. Для этого им нужно дать возможность строить большие, двухуровневые сети, лишенные постоянных проблем иерархических сетей. И было бы еще лучше, если бы эта концепция охватывала не одну, а множество сетей, тем самым намного упрощая проблему мобильности приложений и предотвращения аварий. Точно также как в свое время сеть стала поддерживать передачу различных мультимедийных данных в масштабе реального времени, теперь она должна приспосабливаться к изменениям, связанным с виртуализацией и динамичными компьютерными средами.
Это не совсем так. Действительно, приложение и гостевая операционная система, наверное, не видят никакой разницы, но сетевым администраторам и службе безопасности это совсем не безразлично. Виртуальная машина больше не начинается и не заканчивается на одном конце кабеля Ethernet. Фактически, ее трафик может вообще не иметь отношения к данному кабелю, если она общается с другой виртуальной машиной в пределах одного и того хоста. Или же она может по нескольку раз в день переходить с одного хоста на другой, занимая тем самым гигабайты трафика (виртуальная машина и система хранения данных). Поэтому гораздо разумнее ввести в «облаке» функцию регистрации всех этих миграций, назначить этим виртуальным машинам определенные политики (безопасность, функция QoS, ролевая система доступа, и т. д.), чтобы ограничить их перемещение в определенные места, и, тем самым, расширить возможности службы технической поддержки. Большинство администраторов виртуальных машин было бы радо получить такие возможности, особенно сейчас, когда у них стали требовать данные о виртуальных машинах, резервном копировании, восстановлении в аварийных ситуациях, гостевой операционной системе, системе хранения данных и всех остальных элементах, которые так или иначе связаны с виртуализацией.