Облачные вычисления *

Apache CloudStack представляет собой универсальную платформу управления средами выполнения виртуальных машин (часто такие продукты именуются “панель управления облаком VPS”). Использование Apache CloudStack (далее, ACS) дает администратору возможность развернуть облако с требуемыми сервисами в короткий срок, а после развертывания эффективно управлять облаком в течение всего жизненного цикла. В рамках данной статьи даются рекомендации по дизайну облака, который может использоваться на практике и подходит для большинства провайдеров публичных облаков, планирующих построение публичных облачных сред малых и средних размеров, обладающих максимальной простотой администрирования и не требующих специальных знаний для отладки и обнаружения проблем. Статья не является пошаговым руководством настройки Apache CloudStack.

Статья описана в форме набора рекомендаций и соображений, которые могут быть полезны при развертывании нового облака. Данный стиль изложения навеян тем фактом, что автор планирует в скором времени развертывание нового облака по данной топологии.

Облако с описанным в статье дизайном успешно используется для оказания коммерческих услуг по аренде VPS. В рамках облака развернуто хранилище на 16 ТБ, состоящее полностью из SSD накопителей Samsung Pro 850 1TB, организованное в программный RAID6, 176 ядер Xeon E5-2670, 768 GB RAM, сеть на 256 публичных адресов.

Давно уже ребята задают вопросы, как организовать резервное копирование в облако, при этом не тратя много сил, времени и лучше всего бесплатно. Поводом для написания статьи послужил очередной диалог на эту тему. По итогами долгой переписки с коллегами, объяснения теории и перебора вариантов практической реализации, я решил написать об этом. Все просто как пять пальцев, но часто спрашивают КАК.

Резервное копирование в облако — тема уже давно не новая. Каждый выбирает своего облачного провайдера, свои инструменты для копирования и пр. Вендоров много, здесь мы рассмотрим именно Google Cloud Platform. Мы все реализуем самыми простыми скриптами, без покупки софта, покупки дисковых хранилищ и прочего.

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

Когда говорят «облачная виртуальная машина», как правило, имеют в виду AWS. И когда все эти вопросы стали для меня актуальными, из любопытства решил провести небольшой эксперимент по оценке цены/скорости систем других крупных облачных конкурентов.



Самое интересное, что по мере разматывания клубка во всей этой облачной истории внезапно всплыл один подвох, который перетасовал всю колоду. И у меня до сих пор нет ответа на вопрос, а как вообще можно вот так вот торговать мощностями, как делают это два упомянутых в заголовке гранда?
Кому интересно — добро пожаловать под кат.

Расходы Cronitor на AWS за последние 12 месяцев

В первые 30 дней после перевода Cronitor на AWS в январе 2015 года мы собрали платежей на $535 и заплатили $64,47 за хостинг, передачу данных и доменное имя. С тех пор мы наращивали потребление услуг, апгрейдили инстансы, добавляли сервисы. Несмотря на репутацию AWS как дорогого пистолета, чтобы выстрелить себе в ногу, наши счета сохранялись на уровне 12,5% от дохода. Смотрите сами.

Сколько я занимаюсь ИТ — столько я слышу от админов «больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу». И ровно столько же у меня возникает вопрос: какое ваше дело?

Давайте забудем, что мы ИТ-шники и управляем клёвыми СХД, фермами серверов, почтовыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.

1. Чем занимается ваша компания?

Забудьте про производство туалетной бумаги, штанов или даже авиадвигателей.

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

Известный факт: мы в JUG.ru Group не делаем конференции просто так, обычно за идеей каждого нового проекта лежит какая-то проблема. Такая нашлась и у нас.

Когда мы были молоды и веселы и использовали генераторы статичных сайтов на Node.js (по секрету скажу, что мы продолжаем их использовать), с нами приключилась вот такая история. Мы только переехали на AWS и взяли самый простой EC2-инстанс, наивно полагая, что 10 Gb пространства на десяток статичных сайтов нам хватит. Однако, в один прекрасный день мы начали ловить ошибки от сервера о том, что место на диске… кончилось. 10 сайтов на 10 Gb пространства. Конечно, мы не поверили вражьим сообщениям и достаточно быстро установили, что на самом деле кончились inode.

Беглый поиск выявил мерзкого виновника — это был JavaScript Node.js, а именно папка node_modules. Посчитали inode, и поняли, что их там добрая сотня тысяч. Оокей, подумали мы и прикрутили еще 100 гигов. И сейчас все хорошо: 630k inode занято, зато есть еще 6kk сверху под зависимости Node.js. Надеюсь, нам хватит этого на ближайшие полгода… А к тому времени, когда они начнут заканчиваться, на новой конференции мы узнаем, как элегантно решить эту проблему.

А если серьезно, то 20 октября мы проведем DevOps-конференцию DevOops 2017 Piter. Один день, три трека, все как вы любите. Кто будет выступать, что будем обсуждать и другие подробности — под катом.

Начинаем публиковать материалы с форума «Совместная безопасность облачных решений для бизнеса», который мы провели совместно с «Лабораторией Касперского» и HUAWEI 31 мая в Москве. Одноименная пленарная сессия оказалась центральным событием и мы решили начать с нее. Участники дискуссии представили свои решения по обеспечению безопасности в облаке, а присутствующие потребители услуг оценили их по существу. Что получилось в итоге — читайте, смотрите.

Участники:

Модератор дискуссии: Никита Цаплин, управляющий партнер RUVDS
Владимир Островерхов, эксперт поддержки корпоративных продаж «Лаборатория Касперского»
Михаил Сергеев, директор по корпоративным коммуникациям ГАРС телеком
Данила Чежин, директор по продажам Variti
Сергей Слукин, руководитель отдела DMA и алгоритмической торговли АО «ФИНАМ»
Станислав Погоржельский, продакт менеджер HOSTKEY
Александр Мисюрев, директор по развитию AIG
Александр Миляр, эксперт по информационной безопасности HUAWEI
Франк Харцхайм, CEO, Deltalis
Лидия Шрейдер-Стрюб, руководитель продаж Deltalis

С появлением application programming interface или, если кратко, API, жизнь программистов стала несколько легче, чем раньше. За минимальное время теперь можно добавить в свое приложение определенные функции, структуры, процедуры, предоставляемые другим приложением, операционной системой или сервисом. API своих сервисов и приложений сейчас открывают многие разработчики.

В 2013 году компания IBM открыла сразу три API когнитивной системы Watson в рамках “The Watson Ecosystem” — экосистемы, которая на то время включала более 40 различных технологий. Благодаря этим API разработчики получили возможность встраивать в собственные приложения и сервисы возможности, предлагаемые IBM Watson. Сейчас открытых компанией IBM API гораздо больше, чем три, да и сами сервисы стали более функциональными. В продолжении — описание существующих API различных сервисов, к которым может получить доступ разработчик.

В соответствии с социологическим опросом 2017 года «Приоритеты сферы информационных технологий», проведенным компанией TechTarget и опубликованным в Computer Weekly, 40 % руководителей компаний, расположенных в странах Юго-Восточной Азии, в 2017 году планируют реализовать программу перехода на облачное хранение данных, а еще 40 % планируют запустить облачные резервные проекты.

Мы с коллегами не так давно обсуждали динамичность развития технологий и перспективы развития облачных вычислений. И как раз наткнулась на статью.

Каждая новая технология приходит на смену старой. Иногда, как и в случае с облаком, проводится ребрендинг старых технологий, чтобы сделать их более привлекательными для потребителей и, тем самым, создать иллюзию нового продукта. Облачные вычисления ранее существовали в той или иной форме. На одном из этапов они назывались «on demand computing» (компьютерные ресурсы по требованию), а затем преобразовались в «application service provider» (ASP).

Последние года два мой отдел плотно занимается проектами миграции корпоративных почт с зарубежных сервисов в MS Exchange на базе инфраструктуры наших дата-центров. Из облачных сервисов типа Office 365, Gmail в основном мигрируют из-за ФЗ-242, так как хотят, чтобы почта жила на российской инфраструктуре. Это не единственная причина: часть компаний после миграции целиком передает нам почтовую систему на администрирование под жесткий SLA, что не всегда можно получить в массовых сервисах. Те, у кого почта раньше жила на железе и кто хочет расширяться, не связываясь с покупкой нового оборудования, также обращаются к нам, скромному российскому облачному провайдеру.

На 27 проектах миграции и 50 тыс. перенесенных ящиков бывало всякое. Сегодня хочу рассказать, что нужно учесть и продумать, если собрались переезжать.

Перевод этой статьи – наш вклад в ликвидацию безграмотности потребителей облачных услуг. Будьте бдительны!

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

В нашу интернет-эпоху информационная безопасность ставится во главу угла. Этому можно не удивляться, поскольку данных в сети чрезвычайно много, а пользователей — миллиарды. Если злоумышленники получат доступ хотя бы к малой толике всей этой информации, можно ждать беды (что, собственно, случается с завидной регулярностью). Конечно, эксперты по безопасности работают, различные компании выпускают инструменты, позволяющие, теоретически, уберечься от вмешательства злоумышленников в нормальный рабочий процесс.

Но, несмотря на принимаемые меры, проблемы зачастую возникают даже у самых, казалось бы, защищенных компаний и организаций. Недавно стало известно, например, что из-за массового распространения в сети вируса WCry в некоторых областях России даже пришлось отменить выдачу водительских прав. Этот вирус скомпрометировал многие компьютеры, которые без разблокировки практически невозможно использовать. Что будет, если сети достаточно крупной коммерческой компании заблокирует вирус? Такая компания потерпит многомиллионные, а то и миллиардные убытки. Так оно и есть, сейчас остановить эпидемию WannaCry удалось только чудом, а убытки еще никто не подсчитывал.

Около месяца назад компания Dell EMC представила Dell EMC Cloud для Microsoft Azure Stack — платформу, которая позволит оптимизировать внедрение гибридных облачных решений на базе Microsoft Azure Stack. И пока она еще не доступна для заказа, мы вкратце расскажем о ее основных преимуществах и о том, что она даст клиентам.

Мы уже знакомы с многими терминами в мире облачных технологий, таких как «Платформа как сервис» (PaaS), «Программное обеспечение как сервис» (SaaS ), «Инфраструктура как сервис» (IaaS). Последним, присоединившимся к этому списку, стало словосочетание «Идентификация как сервис» (IDaaS).

Решения Ansible гарантируют максимальную гибкость. Это позволяет сообществу находить все новые способы использования модулей Ansible для автоматизации часто выполняемых операций на многих уровнях, в том числе в сочетании с технологиями OpenStack.

В этом блоге мы будем обсуждать многочисленные варианты использования Ansible, самого популярного программного обеспечения (ПО) для автоматизации, совместно с OpenStack, самым популярным ПО для облачной инфраструктуры. Мы поможем вам понять, как и почему вам следует использовать Ansible, чтобы сделать свою жизнь проще с помощью комплексной автоматизации (Full-Stack Automation), как мы любим ее называть.

Привет, Хабр! Сегодня мы хотели бы поднять проблему нагрузочной балансировки в Облаке, а точнее обсудить новый подход к принятию решения о живой миграции виртуальных машин между хостами, предложенный Дорианом Минаролли, Артаном Мазрекай и Берндом Фрайслебеном в их исследовании «Tackling uncertainty in long-term predictions for host overload and underload detection in cloud computing». Вольный перевод этой статьи мы сегодня публикуем.

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



Динамическими рабочими нагрузками в облачных вычислениях можно управлять с помощью живой миграции виртуальных машин с перегруженных или недогруженных хостов на другие узлы для экономии электроэнергии и снижения потерь за нарушение соглашения об уровне обслуживания (SLA). Проблемой является верное определение момента перегрузки хоста в будущем для своевременного проведения живой миграции.

Всем привет! Сегодня решили поднять тему уже полностью вошедших в нашу жизнь облаков, а в частности – облачного хранилища именно в бизнесе. Тема не нова, но мы решили поговорить об этом, поскольку сами не далее как в прошлом году выпустили собственную облачную платформу, а пару дней назад начали официально предоставлять на ней услугу хранилища. Почему мы решили запустить именно эту услугу, что она несет для клиента, на что ориентировались при ее создании, на кого из конкурентов ровнялись и, что за хранилище в итоге у нас получилось? Welcome ниже.

В этой пятничной статье мы хотим немного поразмышлять о перспективах развития направления мобильных сервисов и приложений в контексте использования облачных вычислений для обработки пользовательских данных. На наш взгляд набирает обороты тенденция, согласно которой персональные устройства становятся тонким клиентом для осуществления ресурсоёмких операций.