Как запускать программы из облака

Запускаем новый, развернутый в облаке Web-сервис и видим привычное изображение активизированной страницы с нашим сообщением (рис. 20.19). Однако теперь мы достигли качественно иного этапа: это наше (первое) облачное приложение, которое можно использовать как часть доступных в облаче Azure сервисов.

увеличить изображение
Рис. 20.19. Запуск приложения из облака по URL-адресу

Копирование URL-адреса из облака в браузер и запуск по URL-адресу

Копирование URL-адреса нашего сервиса выполняем через AppFabric, через пункт контекстного меню copy (рис. 20.20).

увеличить изображение
Рис. 20.20. Копирование URL-адреса из облака в браузер

21. Запуск приложения по его URL-адресу, взятому из облака

Запускаем браузер и выполняем paste в его строку URL-адреса. Работает! (рис. 20.21).

увеличить изображение
Рис. 20.21. Запуск приложения по его URL-адресу, взятому из облака

Отслеживание запущенного облачного приложения

Отслеживаем запущенное облачное приложение через AppFabric (рис. 20.22).

Удаленный рабочий стол на Windows VDS (VPS сервер). Как запускать программы и решать задачи 24/7

Наш пример завершен.

увеличить изображение
Рис. 20.22. Отслеживание запущенного облачного приложения

Заключение

В данной лабораторной работе Вы познакомились с тем, как разработать приложение для облака Windows Azure. Отметим, что даже для автора курса, весьма опытного в подобных вопросах, изучение и изложение материала на эту тему доставило искреннее удовольствие и вызвало мой профессиональный интерес.

Желаю успешной разработки облачных приложений.

1. Справка и поддержка на портале Windows Azure (Разработка приложений).

Источник: intuit.ru

Запустите ваши любимые программы из облака с помощью Cameyo

Еще пару лет назад запуск приложений с USB-накопителей был практически невозможен. В наши дни многие пользователи носят портативные версии своих любимых приложений на USB-накопителях, чтобы иметь доступ к любимым программам из любой точки мира. Создание портативной версии программного обеспечения также стало намного проще благодаря таким приложениям, как Cameyo.

В наши дни большая часть пользователей ПК использует облачные сервисы для быстрого выполнения своей работы без необходимости загружать или устанавливать приложения. Например, многие пользователи используют онлайн-сервисы для сжатия PDF-файлов.

Точно так же многим пользователям, которым часто нужно переключаться между различными компьютерами, может понравиться идея запуска приложений из облака, чтобы избежать установки Windows на USB-накопитель и повсеместного использования USB-накопителя.

Запускать программы из облака с Cameyo

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

Как пользоваться облаком на телефоне

Главное в том, что вам не нужно ни устанавливать программное обеспечение, ни платить за запуск любимых программ из облака. Вам просто нужно обратиться к Cameyo, той же службе, о которой мы говорили несколько дней назад, для создания переносимой версии приложений Windows.

Cameyo делает запуск приложений из облака простой задачей. На момент написания этой статьи были доступны сотни приложений в 10 различных категориях. Такие приложения, как Firefox, Opera, Chrome и Maxthon доступны в категории «Браузер».

Доступные виртуализированные программы

Популярные медиаплееры, такие как VLC, GOM, KMPlayer и Winamp, можно найти в категории «Медиа», что означает, что вам не нужно устанавливать или загружать переносную версию VLC или GOM, чтобы смотреть любимое видео на компьютере. Такие приложения, как TeamViewer, 7-Zip, Glary Utilities и VirtualBox, доступны в разделе Utilities.

Чтобы запустить программу, просто наведите курсор мыши на значок приложения, чтобы раскрыть подробности, загрузить и выполнить кнопки. Нажмите кнопку «Выполнить в браузере» для Cameyo, чтобы начать буферизацию программы. В зависимости от размера программы и скорости вашего интернет-соединения, время, необходимое для буферизации программы, может быть очень большим. Но как только он загружен, как видео, все гладко.

Например, чтобы запустить проигрыватель VLC, перейдите к категории «Медиа», наведите указатель мыши на значок проигрывателя VLC и нажмите кнопку «Выполнить в браузере», чтобы запустить программу на новой вкладке. Иногда выполнение выбранной программы может занять несколько секунд (от 5 до 10 секунд).

Добавьте ваши любимые приложения

Кроме того, если вы обнаружите, что ваша программа недоступна в списке, вы можете загрузить любимую программу несколькими щелчками мыши, зарегистрировавшись в службе (бесплатно). Для этого после входа в свою учетную запись Cameyo нажмите кнопку «Добавить приложение», расположенную на боковой панели, выберите «Создать новый пакет Cameyo» (из установщика программного обеспечения), введите URL-адрес установщика приложения и нажмите кнопку «Отправить». Таким образом, вы можете добавлять свои любимые программы одним нажатием, не загружая ничего на свой ПК.

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

Как вы можете видеть, интерфейс CAMEYO прост в навигации. Хотя некоторые приложения, доступные на Cameyo, не обновлены, вы можете добавить последнюю версию этих приложений, следуя вышеупомянутому методу. Например, приложение Opera в последний раз обновлялось в апреле 2014 года, но большинство приложений обновлены.

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

Источник: ru.athowto.com

Как запускать в облаке приложения, требовательные к latency? СУБД Arenadata DB на сверхбыстрых облачных дисках

Источник

Arenadata DB — мощная распределенная аналитическая база данных для высоконагруженных проектов. Эта СУБД может в короткие сроки обслуживать огромное количество аналитических запросов к данным, но такой режим работы делает ее требовательной к производительности дисков: она должна быть высокой, чтобы обеспечить быстрый отклик системы. Из-за этого Arenadata DB не так просто развернуть в облаке: «под капотом»‎ должны быть быстрые диски и возможность выбора их типа с учетом нагрузки проекта — для достижения нужной скорости работы.

Обычно облака не гарантируют скорости отклика, подходящей для работы со сверхнагруженными системами. Но на платформе Mail.ru Cloud Solutions запущена полностью управляемая Arenadata DB Cloud и есть быстрые диски для ее работы High IOPS SSD. Их производительности вполне достаточно для большинства приложений. А для систем с особо высокими нагрузками, где критически важно минимизировать время отклика до десятых долей миллисекунды, теперь можно подключить и сверхбыстрые диски Low Latency NVMe — они предназначены для задач, где скорость отклика выходит на первый план.

Меня зовут Дмитрий Яценко, я являюсь преподавателем-исследователем в Южном федеральном университете, тренером по продуктам в Arenadata, а также по совместительству разработчиком и системным интегратором в других организациях. В этой статье я покажу результаты тестирования Arenadata DB c Low Latency NVMe, которые помогли улучшить производительность СУБД при по-настоящему высоких нагрузках.

Быстрые и сверхбыстрые диски: как сделать правильный выбор?

Достаточная производительность дисков в основном зависит от того, какие запросы будут выполняться над данными и от числа этих запросов. Нельзя сразу сказать, какая производительность дисковой подсистемы потребуется на конкретном проекте: итоговое значение зависит от многих факторов.

По исходным данным о проекте можно подобрать число нод, процессоров, объем дисков, но производительность получится определить только с помощью тестов. Так, для Arenadata DB провайдер Mail.ru Cloud Solutions рекомендует использовать один из двух видов дисков:

• быстрые High-IOPS SSD — повсеместно используемые отказоустойчивые диски, имеют время отклика и полосу пропускания, подходящие для подавляющего большинства применений. Но для очень высоких нагрузок их возможностей может не хватать;
• сверхскоростные Low Latency NVMe, у которых большая пропускная способность (и величина IOPS) по сравнению с High-IOPS SSD, а гарантированное провайдером время отклика дисковой подсистемы при нагрузках составляет не более 0,5 мс (для блока 4 KB). Они идеальны для сверхнагрузок. Отказоустойчивость этих дисков обеспечивают два инструмента: регулярный снапшот дисков, который производит платформа и RAID-режим работы дисков NVME. Оба инструмента гарантируют отказоустойчивость и доступность данных в любой момент без задержки производительности.

Тип диска	Размер блока	Чтение		Запись
		IOPS	MB/с	IOPS	MB/с
High IOPS SSD	4КB	10000	39	6250	24
	64КB		313		195
	1MB		500		500
Low Latency NVMe	4КB	18750	73,24	8750	34,18
	64КB		350		250
	1MB		585,94		500

Для блоков 4KB гарантируется время отклика (latency) 0,5 мс.

И для каждого проекта встает вопрос: достаточно ли будет High-IOPS SSD или их скорости мало, лучше подключить Low Latency NVMe? Любые Highload-нагрузки нужно тестировать: High-IOPS SSD дают очень хорошие цифры, но для по-настоящему нагруженных систем их бывает недостаточно.

Возможность подключить в облаке сверхбыстрые Low Latency NVMe позволяет использовать облака для таких категорий приложений, где ранее это было недоступно из-за недостаточной скорости отклика.

Ниже я покажу результаты одного такого теста по выбору типа дисков. Вы увидите, какие показатели дают Low Latency NVMe, а также сможете соотнести результаты с вашими требованиями, чтобы определиться, подойдет ли такой вариант вашему приложению.

Задача тестирования

В процессе тестирования мы проверяли работоспособность СУБД Arenadata DB и оценивали результаты, демонстрируемые системой. Как я уже говорил, она использует много ресурсов. Решение построено на Greenplum — MPP-системе, работающей на основе PostgreSQL.

Внутри одного кластера Greenplum могут размещаться сотни логических сегментов — инстансов PostgreSQL, распределенных по различным серверам (сегмент-хостам). Каждый инстанс отвечает за обработку своей части данных. При выполнении запроса все инстансы работают одновременно.

В результате генерируется значительный объем трафика: растет нагрузка на сеть, CPU и дисковые подсистемы.

Внутри Greenplum есть встроенная утилита GPCHECKPERF, которая позволяет тестировать нагрузку на диски и сеть. В ее основе работает Linux-утилита dd: создается файл заданного объема, для которого проводится запись и чтение данных с измерением скорости. Так как Greenplum — MPP-система, подобные тесты необходимо одновременно и параллельно выполнить на всех узлах кластера (сегмент-хостах). С помощью этой утилиты я провел комплексную оценку скорости чтения/записи дисковой подсистемы. Точно так же протестировали сеть — есть встроенная утилита GP, которая запускает пакеты данных между узлами кластера, анализируя пропускную способность сети.

В ходе тестирования хотели достичь следующих показателей:

• Пропускная способность сети не менее 1 Гбит/с. Это минимальная скорость передачи данных по сети, которая необходима для работы Greenplum. Если этот показатель меньше, сеть может стать узким местом, что приведет к замедлению обработки запросов.
• Скорость чтения и записи дисковой подсистемы не менее 0,8 Гбит/с. Чем выше этот показатель, тем быстрее происходит считывание и запись данных с диска.
• Время отклика (Latency) не более 100 мс. Хотя со стороны Greenplum нет жестких рекомендаций для данного показателя, желательно, чтобы его величина была минимальной.

Первые тесты производительности СУБД Arenadata DB на дисках High-IOPS SSD

Стенд для первого теста (рис. 1) — 16 серверов (8 CPU для каждого сервера) и 64 GB RAM. На каждом сервере (сегмент-хосте) размещалось по 4 основных логических сегмента (инстанса PostgreSQL) и 4 вспомогательных. Вспомогательные сегменты выполняли роль «зеркал» для повышения отказоустойчивости.

Утилита GPCHECKPERF размещалась на мастер-сервере и запускала утилиту dd параллельно на всех сегмент-серверах. Та, в свою очередь, сначала записывала данные в файл, а затем считывала их, анализируя скорость дисковой подсистемы. Еще одна утилита GP измеряла скорость передачи файла по сети от одного сегмент-хоста к другому, тестируя таким образом полосу пропускания канала.

Рисунок 1. Стенд для первого теста: 16 сегмент-хостов по 4 основных и 4 вспомогательных сегмента в каждом

По нагрузке на сеть для Arenadata DB требовалась минимальная пропускная способность 1 Гбит/с. В тестах на стандартных машинах с дисками High-IOPS SSD я достиг данного показателя, применив специальную настройку сети Multiqueue, которая помогает задействовать CPU виртуальной машины для обработки трафика между серверами.

Минус такого решения: CPU задействованы в обработке трафика, то есть больше ресурсов уходило на обработку, а не на дополнительные вычисления внутри кластера.

По нагрузке на дисковые подсистемы диски High-IOPS SSD дали хорошую производительность в рамках SLA, но в рамках поставленной задачи их скорости было недостаточно.

В процессе тестирования на разных дисках была показана скорость чтения/записи — от 320 до 550 Мбайт/с (рис. 2), время отклика дисков — около 25 мс (рис. 3). Это допустимые показатели — нагрузка на разные компоненты может варьироваться, так что производительность с точки зрения клиентской нагрузки также будет меняться.

При этом показатели в пределах SLA и тестирование подтвердит, что всё в порядке. В большинстве случаев такой производительности дисков будет вполне достаточно, но в рассматриваемом случае я рассчитываю на лучшие показатели.

Рисунок 2. Значения скорости записи дисковой подсистемы, полученные по 16 сегмент-хостам, которые использовались во время первого тестирования (на дисках High IOPS SSD)

Рисунок 3. Значения времени отклика, полученные по 16 сегмент-хостам, которые использовались во время первого тестирования (на дисках High IOPS SSD)

Рисунок 4. Значения IOPS, полученные по 16 сегмент-хостам, которые использовались во время первого тестирования (на дисках High IOPS SSD)

Небольшой экскурс о том, откуда берется разница в производительности на этом типе дисков, почему есть разброс скорости от 320 до 550 Мбит/с.

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

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

Итак, после тестов с дисками High-IOPS SSD стало понятно, что нам нужны диски более производительные, чем High-IOPS. Ну а если говорить формальным языком, то для нас это означало, что нам нужен повышенный SLA и новый тип дисков.

Второе тестирование СУБД Arenadata DB с дисками Low Latency NVMe

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

Стенд для второго теста (рис. 5) — 10 виртуальных машин (16 CPU на каждый сервер) и 64 GB RAM. Архитектура и схема взаимодействия компонентов идентична первому тесту, с той лишь разницей, что вместо 16 сегмент-серверов использовано 10. На каждом сервере так же размещалось по 4 основных и 4 вспомогательных сегмента (инстанса PostgreSQL).

Рисунок 5. Стенд для второго теста: 10 сегмент-хостов по 4 основных и 4 вспомогательных сегмента в каждом

Использование Low Latency-дисков сейчас подразумевает подключение High-Freq-флейворов серверов, где в два раза больше CPU и повышенная частота процессора (Basic/Advanced — 2,2 ГГц, High-Freq — 3,0 ГГц).

По пропускной способности сети получили увеличение в 10–15 раз — 10–15 Гбит/с.

По дисковой подсистеме получили хорошие результаты по скорости записи (1,1 Гбайт/с) и чтения (1,2 Гбайт/с) (рис. 6) На всех серверах скорость была одинаковой на всех дисках. При этом время отклика составила не более 0,3 мс (рис. 7) — что даже лучше, чем задекларированный для этих дисков SLA Mail.ru Cloud Solutions, который равен 0,5 мс. Скорость отдачи запросов внутри СУБД также значительно увеличилась.

Рисунок 6. Значения скорости записи дисковой подсистемы, полученные по 10 сегмент-хостам, которые использовались во время второго тестирования (на дисках Low Latency NVMe)

Рисунок 7. Значения времени отклика, полученные по 10 сегмент-хостам, которые использовались во время второго тестирования (на дисках Low Latency NVMe)

Рисунок 8. Значения IOPS, полученные по 10 сегмент-хостам, которые использовались во время второго тестирования (на дисках Low Latency NVMe)

Процесс внедрения нового типа диска требует немного времени: создается виртуальная машина с параметрами, выбирается тип диска, разворачивается СУБД. Вся установка Arenadata DB заняла около часа. С техническими проблемами в процессе тестирования не столкнулись.

Замечание: вполне ожидаемо, что у меня возникли вопросы о надежности дисков, которые я адресовал владельцам платформы. Как мне пояснили, несмотря на то, что диски Low Latency являются локальными и физически установлены в гипервизор, они резервированы, что позволяет производить замену диска без прерывания сервиса. При необходимости обслуживания гипервизора облачная платформа также предоставляет возможность миграции виртуальной машины и дисков на другой гипервизор с аналогичными дисками без прерывания сервиса.

Основной результат

Тестирование показало возможность успешного использования Arenadata DB as a Service на платформе Mail.ru Cloud Solutions как на быстрых, так и на сверхбыстрых дисках. В обоих случаях гарантируется быстрая и стабильная работа дисковой подсистемы. Однако использование дисков Low Latency NVMe увеличивает скорость обработки запросов и больше подходит для задач, в которых скорость отклика критична. Это важно, так как СУБД используют в проектах, где IT-инфраструктура должна быстро и безошибочно обрабатывать сложные аналитические запросы над большим объемом данных: ритейл, банки, предприятия общественного питания, провайдеры контента и игровых платформ, биржевые и финансовые сервисы.

Сегодня на платформе Mail.ru Cloud Solutions также стала доступна Enterprise-версия Arenadata DB Cloud с расширенной поддержкой от разработчика решения. С этой версией также можно использовать сверхбыстрые диски Low Latency NVMe. Если вы хотите протестировать Arenadata DB в облаке и проконсультироваться по тонким настройкам, вы можете оставить заявку на странице решения.

UPD: Исправили ошибки в таблице. Спасибо amarao, что обратил внимание.

Что еще почитать:

1. Как реализуется отказоустойчивая веб-архитектура в платформе Mail.ru Cloud Solutions
2. Быстрые и сверхбыстрые диски в облаке: как получить максимум от облачной системы хранения данных
3. Наш Телеграм-канал об облачных технологиях и цифровизации

• arenadata db
• субд
• dbaas
• highload
• vk cloud
• высоконагруженные приложения
• высоконагруженные системы
• iops
• nvme
• greenplum
• vk cloud solutions
• mail.ru cloud solutions

Источник: habr.com