После моих первой и второй статей об Apache CloudStack ко мне обратился пользователь с вопросом о том, как организовать высокодоступный управляющий сервер ACS с использованием Galera. Ранее я не использовал такую топологию развертывания, но по этому поводу решил попробовать выполнить такую настройку.
В статье описывается метод развертывания отказоустойчивой конфигурации управляющих серверов Apache CloudStack совместно с мультимастер-кластером MariaDB (Galera).Читать полностью »
Давно не брал я в руки шашки… Проблема оказалась глубже и интересней, чем можно было себе представить. Попытаюсь изложить то, что найдено со времени предыдущей статьи.
«Модем горит,
Провайдер плачет.
Но он не смог поступить иначе.
Гремит гроза...»
Гроза! Стихия! Караул! Иной раз тяжело предугадать, какой ущерб она может учинить домашней электронике… Благо, её можно предупредить, тем самым исключив возможность выхода из строя, скажем, хотя бы домашних маршрутизаторов и модемов — обычно они в первую очередь и подвергаются воздействию буйных действ природы.
Когда говорят «облачная виртуальная машина», как правило, имеют в виду 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 различных сервисов, к которым может получить доступ разработчик.
Читать полностью »
Последние года два мой отдел плотно занимается проектами миграции корпоративных почт с зарубежных сервисов в MS Exchange базе инфраструктуры наших дата-центров. Из облачных сервисов типа Office 365, Gmail в основном мигрируют из-за ФЗ-242, так как хотят, чтобы почта жила на российской инфраструктуре. Это не единственная причина: часть компаний после миграции целиком передает нам почтовую систему на администрирование под жесткий SLA, что не всегда можно получить в массовых сервисах. Те, у кого почта раньше жила на железе и кто хочет расширяться, не связываясь с покупкой нового оборудования, также обращаются к нам, скромному российскому облачному провайдеру.
На 27 проектах миграции и 50 тыс. перенесенных ящиков бывало всякое. Сегодня хочу рассказать, что нужно учесть и продумать, если собрались переезжать.Читать полностью »
