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

Источник

Всем привет! Сегодня хотим поговорить об облачных базах данных, а точнее о тех проактивных и разовых мероприятиях, которые непосредственно обеспечивают их производительность.

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

Мы проделали большую работу, запуская и оптимизируя свою новую услугу облачной базы данных на собственной платформе Техносерв Cloud и, конечно же, столкнулись с рядом проблем и выработали свои подходы к их решению. Сейчас, когда сервис протестирован и работает, мы хотим поделиться с вами своим опытом – уверены, что прочитав этот материал, вы сможете избежать повторения чужих ошибок или откроете для себя что-то новое.

Многие владельцы интернет-ресурсов размещают свои веб-приложения на виртуальных серверах или же задействуют shared-хостинг. В данной статье мы постараемся детально рассмотреть обе услуги, и на основе опыта службы поддержки клиентов CloudLITE выведем заключение: какой из этих услуг можно отдать свое предпочтение и при каких обстоятельствах. Все подробности читайте под катом!

Источник

Не так давно мы рассказали о запуске нашей новой облачной услуги – объектного хранилища Техносерв Cloud, совместимого с S3. Сегодня мы хотим перейти к конкретным техническим моментам в работе с нашей услугой, а в частности к настройкам системы резервного копирования для работы с S3-совместимым хранилищем. Сейчас практически все современные СРК имеют встроенную поддержку протокола S3 API, но не все об этом знают и, соответственно, не в полной мере используют функциональность систем.

Недавнее исследование Taneja Group определило приоритеты в использовании объектных хранилищ среди пользователей, согласно которому хранение резервных копий занимает первое место. В качестве примера для сегодняшнего поста мы взяли СРК Commvault. Подробнее об исследовании, о Commvault и настройке подключения облака к системе в нашем новом материале.

Что нам стоит vЦОД построить?

Я долго ждал и просил автора исследования 2014 года повторить его. Не дождался, несмотря на регулярные просьбы. Видимо, представляя какой титанический труд предстоит, автор эту идею откладывал.  Но так совпало, что не только мне, но и моей знакомой для ее компании потребовались облачные услуги, и она предложила мне свою помощь по сбору информации. Так родилась шальная идея повторить статью. Возражений у автора предыдущего обзора не было, поэтому мы принялись за дело, взяв за основу его методику подсчета
В этот раз в обзор вошли 36 компаний, а совместная работа по сбору и анализу информации затянулась аж на 5 месяцев. Конфигурацию мы взяли, опираясь на предыдущее сравнение  с поправкой на требования компании моей знакомой.

• Барух Садогурский (JFrog)
• Олег Анастасьев (Одноклассники)
• Алексей Акопян (Dell EMC)
• Кирилл Толкачёв (Альфа-Лаборатория)
• Александр Тарасов (Одноклассники)

В данной статье рассматривается подход к интеграции Apache CloudStack (ACS) со сторонними системами посредством экспорта событий в брокер очередей сообщений Apache Kafka.

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

«Кто так строит?!»

Какой адрес у маршрутизатора должен быть по-умолчанию в сети – это большой вопрос. На самом деле ничто не мешает ему быть любым адресом из подсети. И сочинители OpenStack тоже решили – давайте будет первый, что мучиться?

После моих первой и второй статей об Apache CloudStack ко мне обратился пользователь с вопросом о том, как организовать высокодоступный управляющий сервер ACS с использованием Galera. Ранее я не использовал такую топологию развертывания, но по этому поводу решил попробовать выполнить такую настройку.

В статье описывается метод развертывания отказоустойчивой конфигурации управляющих серверов Apache CloudStack совместно с мультимастер-кластером MariaDB (Galera).

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

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

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