�ݺ�ߣ

Editor's Notes

1. Для этого воспользуемся известной классификацией 5-3-2, и рассмотрим первую цифру 5. Облако в его самом широком смысле определяется пятью основными характеристиками. Первый – это самообслуживание – клиент может без вмешательства вендора управлять собственными ресурсами – запрашивать дополнительные мощности, организовывать хранение данных в облаке, и так далее.Любой облачный сервис имеет повсеместный доступ – сервис доступен по сети Интернет по стандартным механизмам, с тонкого и толстого клиента (например, мобильных телефонов, ноутбуков, планшетов), с любой платформы. Распределение ресурсов и мультитенантная модель – ресурсы назначаются и переназначаются в зависимости от требования клиентов. При этом клиент не знает, где именно расположены его ресурсы, однако в некоторых случаях может указать географическое расположение, например, страну или регион, в котором будет расположен его сервис. Любой облачный сервис по своей природе эластичен – мощности разворачиваются и настраиваются быстро и часто в автоматическом режиме. Для клиента в данном случае доступные ему ресурсы виртуально не ограничены.Для оплаты облачных сервисов типичной моделью оплаты является модель оплаты по факту использования. Облачная платформа в автоматическом режиме проводит необходимые расчёты (например, количество потребленного трафика, время вычислений сервиса и так далее) и выставляет счёт для оплаты в конце периода.
2. Цель слайда:Объяснить три устоявшихся термина в облачной индустрииТренеру на заметку:Важно понимать, о чем говорить при рассказе о видах предложения облачных сервисов.Есть много недопонимания, когда речь доходит до «облака».Важно понимать, что происходит в индустрии и как мы думаем об «облаке».Выше представлена наиболее часто используемая таксономия типов облачных сервисовВ индустрии определены три типа сервисов:IaaS – набор связанных с инфраструктурой возможностей (ОС, сетевое подключение, etc), предоставляемых клиенту на основе модели «плати-за-использование» и могущих использоваться для размещения приложений. PaaS – функциональность более высокого уровня, связанная с платформой и предоставляемая как сервис для разработчиков приложений. С PaaSразработчики абстрагируются от низлежащей инфраструктуры. SaaS – приложения, предлагаемые в качестве сервисов, когда организации просто потребляют и используют приложение. Традиционно же организация платила бы за использование приложения или приложение монетизировалось бы через доход от рекламы. Важно заметить, что эти три типа сервисов могут существовать отдельно или в комбинации друг с другом.Предложения типа SaaSнеобязательно могут быть разработаны над предложениями PaaS, так как решения, основанные на использовании PaaS, часто предоставляются как SaaS. Предложения типа PaaS– больше, чем просто работающая на IaaSплатформа.
3. Перед созданием электрической сети каждое предприятие нуждалось в собственном генераторе энергии. Развитие в генерации энергии шло в одно время с развитием технологий передачи энергии, её инфраструктуры. Это требовало конструкции различных деталей для передачи и регулирования энергии. С расширением предприятий и развитием процессов производства, детали и изделия становились все более продуманными. Владельцы предприятий должны были нанимать архитекторов для проектирования систем и обученных инженеров для управления этими системами. У ранних интеграторовбыли реальная конкурентоспособная стоимость и преимущество гибкости. Могли бы вы представить постройку фабрики сегодня с изготовлением собственной динамо-машины? Томас Эдисон, General Electric – Постоянный ток (DC)Никола ТЕсла (Westinghouse) – Переменный ток (AC)
4. = развертывание сервиса (легко, даже CEO может это сделать) =Сервис – приложение, которые вы хотите запуститьМодель, конфигурация сервиса – содержит сведения о сервисе, как много экземпляров надо запустить, etc.На данный момент вы должны развертывать сервис через портал. В будущем будет доступно API с возможностью развертывания сервиса через командную строку, TFS-процедуры и прочее.В этом сценарии мы развертываем сервис через портал. Мы загружаем два файла (упакованный пакет сервиса и конфигурацию модели). Fabric-контроллер считывает конфигурацию модели, описывающую, как развертывать наш сервис. В этом случае мы развертываем сервис на три машины. Контроллер определяет, на какие три машины развертывать сервис, копирует на них сервис и запускает. Затем контроллер конфигурирует DNS, чтобы сервис имел точку входа для использования сервисов извне. Также происходит конфигурация балансировщиков нагрузки и маршрутизаторов. Это всё. Всё автоматизировано. Process service model filesDetermine resource requirementsCreate role imagesAllocate compute and network resourcesPrepare nodesPlace role images on nodesCreate & start VMConfigure networkingDynamic IP addresses (DIPs) assigned to bladesVirtual IP addresses (VIPs) + ports allocatedPrograms load balancers to allow trafficGoals:Allocate service components to available resourcesSatisfy constraints (VM size, fault domains)Optionally: satisfy soft constraintsPrefer simplified deploymentsInstances from same update domain on same hostOptimize networkingPut nodes closer togetherLB “probes” guest agent every 15 secondsMiss 2 probes? LB stops forwarding trafficRole can report “busy” to guest agentGuest agent stops responding probesBased on heartbeats, typically 15 secondsUsed for status and recovery Health state sampler resets the index on successful pollOnce index falls below zero, FC attempts to heal nodeHost agent timeout is 10 minutesWorst-case reaction time is timeout interval + heartbeat interval
5. Спасибо! 
6. Спасибо! 