В момент написания этого материала многие лица и организации изложили свою точку зрения относительно <концепции> облачных вычислений (cloud computing), ее преимуществ и недостатков. Однако, необходимо понимать, что термин “облачные вычисления” охватывает большое многообразие как систем и технологий, так и моделей развертывания, <предоставления> услуг и ведения бизнеса. Ряд утверждений, которые иногда делаются относительно облачных вычислений, например, что они “масштабируются” или что они конвертируют капитальные затраты (CAPEX) в операционные (OPEX), являются верными только для определенных видов облачных систем. Цель этого раздела состоит в том, чтобы четко описать разделение систем облачных вычислений или облачных систем на пять значимых сценариев и, для каждого из этих сценариев, объяснить основные аспекты (такие, как масштабируемость), требующие внимания или вызывающие споры, и как эти аспекты адресуются в отношении каждого из сценариев (2).
2) Этот раздел представляет физический - сетевой взгляд на то, как подписчики (облачные потребители - заказчики) сервисов подключены к облачным системам. Понимание облачного и составных частей традиционного “стека” программного обеспечения, доступных для подписчиков является не менее важным и рассматривается в разделах 5, 6 и 7 этого (оригинального) документа.
Как это предполагается в определении облачных вычислений NIST, облачная система является коллекцией ресурсов, доступных по сети для заказчиков (т.е. облачных подписчиков – облачных потребителей). В общем случае, облачная система и ее подписчики применяют модель клиент-сервер, которая предполагает, что подписчики отправляют по сети сообщения серверным компьютерам, которые в ответ на полученные сообщения выполняют соответствующую работу.
Рисунок 1 дает общий взгляд на облако и его клиентов: облачные вычислительные ресурсы описаны как комплекс взаимосвязанных* компьютерных систем, доступ к которым клиенты осуществляют по сети. Как показано на рисунке, могут появляться новые клиенты, старые клиенты могут уходить, в разные моменты времени количество клиентов будет разным. Подобным образом и облако поддерживает пул аппаратного обеспечения, которым управляет для максимизации (увеличения производительности и уровня) сервиса и минимизации издержек. Для поддержки высокой доступности сервисов, несмотря на ожидаемые отказы и истечение срока жизни компонент, облако мере возникновения необходимости** подключает новые и выводит из эксплуатации старые или отказавшие аппаратные компоненты. Облако эффективно управляет пулом аппаратных ресурсов для оптимального, с т.з. издержек, предоставления сервисов. Одна из стратегий <такого управления> состоит в том, что облачный провайдер отключает неиспользуемые компоненты на период сокращения потребностей подписчиков. С позиций ли управления потребляемой мощностью или обновления аппаратного обеспечения, миграция рабочих нагрузок (workloads) заказчиков с одного физического компьютера на другой является ключевой стратегией, позволяющей провайдеру обновлять аппаратное обеспечение и консолидировать рабочие нагрузки без причинения неудобств подписчикам.
*) в данном случае, grid представляется логичным перевести именно так, т.к. облачные вычисления не всегда предполагают использование Grid-технологий. Lingvo Computers даёт следующие определения:
В свою очередь, облачные технологии напрямую не подразумевают (хотя и не отрицают) использование распределения выполнения частей задачи по разным узлам “решетки”, представляющей собой распределенные вычислительные ресурсы, связанные особым образом для выполнения, фактически, массово-параллельных вычислений.
**) наверняка, вы обратили внимание, что в предлагаемых переводах “as needed” и “on demand” переводятся не “по требованию”, а “по необходимости”. Такой выбор обусловлен более мягким и, в определенной степени, превентивным для ряда случаев смыслом “по необходимости”. Требование потребителя, поступившее в той или иной форме, может не всегда соответствовать согласованному уровню сервиса (SLA), а необходимость может быть идентифицирована провайдером сервиса вообще без уведомления об этом клиента. Например, необходимость или потребность выявляется на основе анализа статистики использования пула ресурсов клиентами и прогноза на дальнейший рост утилизации ресурсов, связанный как с увеличением потребностей существующих клиентов в ресурсах, так и с увеличением числа клиентов (экстенсивное или количественное развитие) и/или расширением портфеля предоставляемых услуг того или иного типа (интенсивное или качественное развитие).
Рисунок 1 представляет лишь небольшую часть общих утверждений (соображений, аспектов), характерных для облачных вычислений . Организации предполагают, что использование облачных вычислений должно отражать такие общие положения (представлены ниже). В то же время, многие из утверждений, сформулированные в отношении облачных вычислений (например, что облака могут масштабироваться для очень больших рабочих нагрузок или их применение позволяет заменять капитальные затраты операционными), являются корректными только для определенных типов облаков. Для избежания путаницы, этот документ явно квалифицирует каждое из таких положений для каждого типа облака, где такое положение применимо - т.е. каждое утверждение обладает границами <применимости> содержания (“scope”). Такие границы, используемые в документе, представлены в Таблице 1.
Таблица 1: Сценарии - варианты границ применимости утверждений, используемых в отношении облаков (Scope Modifiers for Statements Asserted About Clouds)
| общий случай, т.е. все варианты облаков (general) |
Применяется для всех моделей развертывания облаков |
| собственное частное облако (on-site-private) |
Применяется к частным облакам, реализованным на площадке заказчика (т.е. полностью контролируемые заказчиком) |
| частное облако на аутсоурсинге (oursourced-private) |
Применяется к частным облакам, размещенным на внешнем хостинге, обслуживаемом аутсоурсинговой компанией |
| собственное облако сообщества (on-site-community) |
Применяется к облакам сообществ, реализованным на площадке заказчиков, составляющих сообщество |
| облако сообщества на аутсоурсинге (outsourced-community) |
Применяется к облакам сообществ, чьи серверы (и другое аппаратное обеспечение – например, системы хранения) размещены на внешнем хостинге, обслуживаемом аутсоурсинговой компанией |
| публичное облако (public) |
Применяется к публичным облакам |
Ниже рассматривается каждый из представленных сценариев границ применимости.
Следующие утверждения являются общими по своим границам применимости, т.е. корректны вне зависимости от модели развертывания или сервисной модели (т.е. модели оказания услуг):
Организации, рассматривающие возможность использования облачных вычислений, должны принимать во внимание эти общие соображения и их возможные последствия для своей бизнес-модели и достижения долгосрочных целей (миссии). Однако, недостаточно уделять внимание только общим аспектам облачных вычислений. Облака также описываются границами применимости одной или нескольких характеристик, представленными в Таблице 1. Организации, обсуждающие применение облаков, должны детально рассматривать аспекты использования различных сценариев (вариантов реализации с учетом границ применимости) облаков, которые являются предметом такого обсуждения. Каждая из альтернатив самостоятельно рассматривается ниже в отдельном разделе (этого и, более обширного, оригинального) документа, фокусируясь на заданных границах применимости (4).
4) Этот документ не повторяет те или иные фрагменты текста. Однако, для конкретных типов облаков, может быть описано больше соображений, значимых для каждого конкретного типа; в этом случае, название общей характеристики/утверждения может использоваться снова, но с объяснением, специфичным для конкретного типа облака.
Иногда утверждается, что при сравнении использования облаков с традиционной моделью “внутренних” (on premises) вычислений, облачная модель требует от подписчиков передачи провайдеру двух важных возможностей, предполагающих высокий уровень доверия подписчика к провайдеру:
Однако, границы контроля и видимости, которые необходимо передать провайдеру со стороны подписчиков, зависят от многих факторов, включая физическое владение и возможность конфигурирования (с высоким уровнем доверия) механизмов защиты границ доступа к вычислительным ресурсам подписчиков.
Этот документ использует концепцию границ доступа (access boundaries) для структурирования и характеристики различных моделей развертывания облаков. Рисунок 2 иллюстрирует ключевую концепцию компьютерной безопасности*, связанную с границами и контролем – периметр безопасности (security perimeter). Как показано на рисунке, периметр безопасности выполняет роль барьера в отношении <операций> доступа: сущности, которые находятся внутри периметра, могут производить свободный доступ к ресурсам, находящимся только внутри периметра; однако, сущности, находящиеся за пределами периметра, могут получать доступ к ресурсам внутри периметра если только это разрешено средствами контроля границ (контроллер границ - boundary controller) на основе применения соответствующих политик доступа. Несмотря не то, что эти термины часто используются при обсуждении сетевых экранов и сетей, концепция периметра безопасности, в действительности. Является более общей и может использоваться, например, для описания границ между различными уровнями привилегий выполнения программного обеспечения, т.е. границ <между> приложениями и операционной системой. Само по себе определение периметра безопасности НЕ является адекватным механизмом обеспечения безопасности. Однако контроль периметра безопасности является важным элементом построения безопасных систем.
*) необходимо отметить, что именно стандарты и рекомендации NIST в области компьютерной/информационной безопасности, в большой степени, определили фундамент и продолжают определять концептуальную основу и подходы к теории и практическому обеспечению безопасности в индустрии информационных технологий.
Типичные контроллеры границ включают сетевые экраны (firewalls), средства блокирования доступа (guards) и виртуальные частные сети (VPN - Virtual Private Networks). Организация может добиться оценки количественных показателей как в отношении контроля использования ресурсов, так и мониторинга доступа к ним (5). Более того, переконфигурируя периметр безопасности, организация может адаптировать его к меняющимся потребностям (например, блокирования или разрешения протоколов или форматов данных, исходя из изменений бизнес-условий).
5) Когда существуют неконтролируемые пути <доступа> к компьютерным ресурсам, периметр безопасности является нарушенным (в оригинале – ослабленным, weakened) или даже отсутствующим. Распространяющиеся беспроводные коммуникации, например, являются угрозой периметру безопасности, начиная с того, что не может быть надежного пути внедрения <контроллера границ> между внешними и внутренними сущностями. Аналогично, многие организации используют мобильные устройства, которые иногда подключаются <к ресурсам>, находясь внутри периметра, а иногда остаются без <должной защиты>, например, во время поездок.Различные модели развертывания облаков, описанные в определении облачных вычислений NIST, подразумевают размещение контролируемого подписчиком периметра безопасности и, следовательно, уровень контроля, который подписчики могут осуществлять в отношении ресурсов, доверяемых облаку (т.е. передаваемых под управление провайдера облака с определенным уровнем доверия этому провайдеру).
Определение облачных вычислений NIST описывает четыре модели развертывания: частное облако (private), облако сообщества (community), публичное облако (public), и гибридное облако (hybrid). Однако, каждая из моделей частного облака и облака сообщества допускают два варианта - сценария <развертывания>, которые должны рассматриваться по отдельности, по причине влияния на периметр безопасности: будет ли он собственный (on-site) или на аутсоурсинге (outsourced). Гибридная модель развертывания является комбинацией других моделей и, поэтому, гибридное развертывание может предполагать и влияние <на периметр безопасности> его элементов - "строительных блоков", и уникальные аспекты влияния, возникающие в результате объединения множества систем в более комплексные интегрированные системы.
4.2 Сценарий собственного частного облака (The On-site Private Cloud Scenario)
Рисунок 3 представляет простой взгляд на собственное частное облако (on-site private cloud). Как показано на рисунке, периметр безопасности простирается вокруг собственных ресурсов подписчика и ресурсов приватного облака. Приватное облако может быть централизованным на одной площадке или распределенным между несколькими площадками подписчика. Периметр безопасности будет существовать только в том случае, если подписчик его реализует. В случае реализации, периметр не гарантирует контроля всех ресурсов частного облака, но его существование дает подписчику возможность осуществлять контроль ресурсов, доверенных собственному частному облаку.
Несмотря на то, что общие предположения остаются верными для собственного частного облака, этот сценарий позволяет предположить и другие, в т.ч. более детально описанные аспекты, которые необходимо принять во внимание организациям, рассматривающим использование собственных частных облаков:
Новый ЦОД - центр обработки данных, датацентр (NewDataCenter): Наиболее прямолинейный подход для подписчика - создать <выделенный> ЦОД, в котором будет развернуто облачное программное обеспечение. В этом случае, собственное частное облако предполагает затраты, аналогичные инвестициям в типичный датацентр и подписчик может подготовить его для ожидаемых рабочих нагрузок.
Трансформация ЦОД (ConvertedDataCenter): В качестве альтернативы созданию нового ЦОД, подписчик может целиком трансформировать существующий датацентр или его отдельные части для поддержки собственного частного облака. Этот подход, однако, может привести к несовместимости параллельного функционирования облачных и обычных необлачных систем в течение периода их сосуществования.
Очистка ресурсов (ScavengedResources): Другим альтернативным подходом является установка облачного программного обеспечения на уже существующие в организации компьютеры. В этом сценарии облачные системы разделяют аппаратные ресурсы с другими формами использования оборудования и могут существенно улучшить утилизацию ресурсов, которые в противном случае могли бы простаивать. Этот подход дает преимущество предложения облачных сервисов на экспериментальной основе без больших инвестиций в оборудование; однако, ресурсы, доступные в такой конфигурации будут ограничены существующими излишками аппаратных ресурсов, присутствующими в инфраструктуре организации (до тех пор, пока предыдущие способы использования оборудования не будут сокращена <до минимума> и оно <в максимальном объеме> не будет передано под использование облака).
Дополнительные ограничения включают:
(1) аппаратные ресурсы должны как можно раньше встраиваться (инкорпорироваться) в собственное частное облако, вне зависимости от того, где они существуют в инфраструктуре организации подписчика (будучи используемыми по сети), несмотря на большую эффективность колокейшена (совместного физического размещения);
(2) доступное оборудование может не быть однородным и это будет приводить к дополнительным сложностям в администрировании.
Релятивисты и позитивисты утверждают, что "мысленный эксперимент" весьма полезный интрумент для проверки теорий (также возникающих в нашем уме) на непротиворечивость. В этом они обманывают людей, так как любая проверка может осуществляться только независимым от объекта проверки источником. Сам заявитель гипотезы не может быть проверкой своего же заявления, так как причина самого этого заявления есть отсутствие видимых для заявителя противоречий в заявлении.
Это мы видим на примере СТО и ОТО, превратившихся в своеобразный вид религии, управляющей наукой и общественным мнением. Никакое количество фактов, противоречащих им, не может преодолеть формулу Эйнштейна: "Если факт не соответствует теории - измените факт" (В другом варианте " - Факт не соответствует теории? - Тем хуже для факта").
Максимально, на что может претендовать "мысленный эксперимент" - это только на внутреннюю непротиворечивость гипотезы в рамках собственной, часто отнюдь не истинной логики заявителя. Соответсвие практике это не проверяет. Настоящая проверка может состояться только в действительном физическом эксперименте.
Эксперимент на то и эксперимент, что он есть не изощрение мысли, а проверка мысли. Непротиворечивая внутри себя мысль не может сама себя проверить. Это доказано Куртом Гёделем.
Понятие "мысленный эксперимент" придумано специально спекулянтами - релятивистами для шулерской подмены реальной проверки мысли на практике (эксперимента) своим "честным словом". Подробнее читайте в FAQ по эфирной физике.
|
|
 |
