Differences

This shows you the differences between two versions of the page.

--- etc:users:kea:introduction_to_cloud_computing_architecture [2010/02/09 09:38] – belka
+++ etc:users:kea:introduction_to_cloud_computing_architecture [2016/08/09 05:23] (current) – ↷ Links adapted because of a move operation 89.163.148.22
@@ Line 106: / Line 106: @@
 Разработчики должны стоить виртуальную машину в следующей иерархии(последовательности) web-сервер, сервер приложения, сервер БД MySQL на образе ОС, установка патчей, изменения  и общих компонентов каждого уровня. Фокусирование на модели (лучше чем образ виртуальной машины) позволяет обновлять по необходимости, по мере добавления в модель новых наборов компонентов.При наличии стандарртной единици развертывания cloud  архитекторы могут использовать "приборы", коотрые помогают обеспечить скорость развертывания  при низкой стоимости. Разработчики должны использовать "приборы", коотрые предварительно настроены для запуска Hadoop на OpenSollaris OS,заимодействую через appliance’s API. Архитекторы могут использовать содержимое коммутаторов для развертывания не как физических устройств, а как виртуальных "приборов"(устройств). Все что необходимо для развертывания-это вщаимодействие с API или GUI.
+==== Стандарты, помогающие решить трудности ====
+Cloud Computing имеет несколько стандартов и стандартных конфигураций,направленных на сокращение стоимости обслуживания и развертывания. Есть стандарты, которые делают процесс развертывания проще, это более важно, нежели наличие совершенно настроенной  окружающей среды для работы. Здесь действует правило 80/20:CC фокусируется на несколькиз стандартов, которые поддерживают 80% всех случаев применения. Стандарт вероятно будет включать тип виртуальной машины, опрационную систему в стандарте образа виртуальной машины и поддержку языков программирования:
+  * Типы виртуальной машины.Применительно к социальным сетям, изоляции для безопасности и высокий уровень абстракции для портирования рекомендуется использовать TypeII виртуальной машины. Для высокой производительности и визуализации приложений, непосредственно для доступа к аппаратуре для достижения максимальной производительности необходимо использовать TYPEI  виртуальных машин.
+  * Предварительно устанавливаемы и настраиваемые системы. программное обеспечение  на виртуальных машинах должно поддерживаться так же как и на физических серверах. Имеется небольшой набор стандартов для поддержки конфигураций, разрешающих расработчикам использовать текущую поддерживаемую VM.
+Когда текущая конфигурация обновляется, модель, диктующая настройки должна быть разработана так,чтобы было легко вносить изменения в новую виртуальныю машину. То же самое должно быть верно для устройств, где текущая версия может быть настроена с помощью стандартных интерфейсов API.
+  * Инструменты и языки. Предприятия должны стандартизировать использование языков java и Ruby on Rails. Малый бизнес может стандартизировать PHP как предпочтительный инструмент для построения приложений. Поскольку эти стандарты достаточно старые в контексте СС, они начинают формировать следующий слой, PaaS(платформа как сервис).
+==== Системы виртуализации и инкапсуляции поддерживают рефакторинг ====
+Кода над приложением производится рефакторинг и создаются путем комбинирования и настройки набор образов виртуальных машин и инструментов"приборов", акцент делается на том, что  конкретная виртуальная машина работает, но  не знает как это реализовано.Виртуализация и инкапсуляция скрывают детали реализации и фокусируют разработчиков на интерфейсах и межкомпонетным взаимодействием.Эти компоненты должны предоставлять стандартные интерфесы для того, чтобы разработчики могли быстро и просто разрабатывать приложения-это как использование тех или иных альтернативных компонентов с похожей функциональностью в зависимости от производительности и скорости. Развертывание приложений производится программно и даже программы развертывания приложений могут быть инкапсулированы  и поэтому могут использоваться повторно. Философия облачных вычисления для поодержки приложений -не устанавливать патчи, а переразвертывать. Управление моделью, которая создает виртуальные образы машин упрощает эту процедуру. После развертывания или выпуска новых версий машин путем обновления компоненты виртуальных машин применяют шаблон проектирования для переразвертывания. Когда разработчики дорабатывают виртуальную машину, только один образ виртуальной машины должен быть создан, остальные должны быть тиражированы и развернуты программно. VM должна иметь версию для облегчения отката в случае необходимости.
+===== Горизонтальное масштабирование =====
+Используя горизонтальное масштабирование следует сосредоточить внимание на общей доступности приложенийс предволожением, что любой из компонентов в люой момент времени может быть не доступен.Большинство платформ облака строятся на виртуальных пулах серверных ресурсов. Горизонтальное расширение не дожно быть ограниченным одним облаком.
+===== Параллелизация =====
+При вертикальном масштабировани , при многопроцессорной машине переллелизация позволяла увеличить скорость выполнения операций. Но сегодня, когда вычислительные среды смещаются к архитектуре  x86 с двумя или четырьмя сокетами, только вертикальное масштабирование имеет много параллельных процессов на ядрах серверов.
+На макроскопическом масштабе, программное обеспечение, которое может использовать распараллеливание на многих серверах может масштабироваться до тысяч серверов, предлагая огромную масштабируемость, это стало возможным благодаря симметричной многопроцессорной обработке.
+В физическом мире, распараллеливание часто реализуется с помощью балансировки нагрузки или содержимым коммутаторов, которые распределяют входящие запросы на несколько серверов.
+Есть много других способов использования параллельной обработки в среде облачных вычислений. Приложение, которое использует значительное количество процессорного времени для обработки пользовательских данных может использовать модель приведенную ниже на рисунке. планировщик получает задания от пользователей,располагает даные в репозитории и далее  запускает новую виртуалдьную машину для каждой задачи,предоставляя виртуальной машине маркер, который позволяет получить данные из хранилища. Когда виртуальная машина заканчивает выполнение своего задания, результат последовательно возвращается обратно планировщику,которые последовательно завершает проект и передает результать пользователю и работы виртуальной машины завершается.
+{{etc:users:kea:shelude1.jpg|}}
+==== Разделяй и властвуй ====
+приложение могут быть распараллелены если  даные могут быть разделены по независимым системам, которые будут обрабатывать их параллельно. Хорошая архитектура приложений включает в себя план разделяй и влавствуй применительно к данным и имеет  реальном мире наглядные примеры и множество подходов:
+  * Hadoop - это реализация MapReduce шаблона, который реализует master/worker паттерн распараллеливания.
+  * БД sharding может быть реализована путям ряда техник разделения, включающих вертикальное разделение,диапазонное разделение или разделение на основе дирректорий. Подход полностью зависит от того, какие данные должны быть использованы.
+  * Большинство финансовых институтов совершенствуют алгоритмы выявления мошенниченства, одни из них -это data-mining операции, которые можно распараллелить применительно к большим объемам дынных.
+  * Другие высокопроизводительные приложения, которые  работают с трехмерной информацией были разработаны так, что состояние одного кубического объема (например газа) может быть вычислено за время t для одного процесса. Далее состояние одного куба-распространяется на состояние восьми прилегающих кубов, которыы вычисляются за всремя t+1.
+Разделение данных имеет значение, когда объемы данных передаются по сети, что делает физические данные следующими в списке рассмотрения.
+==== Физика данных ====
+Физика данных рассматривает связь между элементами процессов и данными, которыми они оперируют. поскольку большинство данных хранятся в облаке, а не на локальных физических серверах, нужно время, чтобы доставить эти данные на сервер.
+Большие объемы данных и низкая пропускная способность канала удлиняет время, необходимое для перемещения данных.
+time=(bites*8)/bandwidth;
+Она очень часто помогает определиться с целесообразность принятия решений, например актуально ли перемещать данные из одного публичного облака в другое и т д
+=== Взаимоотношение между данными и процессами ===
+Перемещение данных из хранилищ для обработки может потребовать большое количество времени и денег
+Некоторые аспекты этих взаимоотношений необходимо рассмотреть:
+    - дыннын хранящиеся без вычислительных мощностей поблизости имеют ограниченную ценность.И облако должнго быть прозрачном в сетевом плане:должны быть известны размер каналов,какова латентность,какова надежность соединенияю. Cloud провайдерам предствоит ответить на все эти вопросы.
+    - Cloud  архитекторы должны иметь способность четко  указать место расположение виртуальных машин и список услуг которые определяют отношения между вируальными машинами и доступом к хранилищу.
+    - Cloud  провайдеры должны оптимизировать эти отношение для клиентов, но так же и равссмотреть вопрос о целесообразности оптимизации эхтих отношений вручную.
+    - иногда более выгодно расчитать значение, нежеди доставать его из сетевого хранилища. Необходим компромис.
+=== программные стратегии  ===
+cloud стратегии как прпавило руководствуются следующими правилами:
+. Перемещение указателей как правило лучше, чем перемещение фактических данных.
+. указатели должны рассматриватся как предосторожность, необходимая для того, чтобы труднее было подделать данные.
+. Объектный доступ. Протокол SOAP.