Рубрика «облако» - 8

Эффективность потребления вычислительных ресурсов - 1
История индустриальной экономики – это история потребления ограниченного ресурса. В случае с электричеством был ярко выраженный вечерний пик, и поэтому владельцы электростанций пролоббировали и современный городской транспорт, и создали с нуля, по сути, индустрию бытовой электроники. То есть поменяли образ жизни миллионов, чтобы электростанции были загружены более равномерно.

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

Байки облака - 1

Сразу предупрежу: это не те байки, где крысу разорвало в хлам. Просто разные мелкие истории «как люди делают», которые могут быть полезны администраторам. А могут и не быть. У нас много довольно крупных заказчиков, и у них, соответственно, компетентные админы. По опыту скажу: часто опытнее там, где есть строгие ограничения по бюджету.

У нас есть заказчик, который перепродаёт наше облако (как оказалось), есть управление выпеканием хлеба из облака, есть даже развёрнутый CTF для обучения хакеров. Но давайте начнём с переездов, в том числе тех, которые возникли из-за перекопанных экскаваторами дорог Москвы.
Читать полностью »

Закупка железа против облака: как правильно считать - 1

Оказывается, что, когда ИТ-подразделение наших заказчиков оценивает затраты на владение собственной инфраструктурой, большая часть из них забывает посчитать, например, электричество. Потому что лицензии и железо оплачивает ИТ-отдел, а тепло-холод-питание — вообще завхоз.

Совокупная стоимость владения физическим оборудованием — вещь сложная, особенно если вспомнить про меняющуюся стоимость денег, покупки в кредит и другие параметры. Давайте я покажу, по какой методике мы считаем и в каких случаях физическое железо лучше.
Читать полностью »

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

Поэтому ещё 5 лет назад, основав «Банду умников» и делая тестовый тираж, мы уже хранили все данные в Dropbox — благо они тогда умещались в бесплатные лимиты. За это время команда выросла с 2 до 35 человек, и в этом году мы поняли, что пора прощаться с Dropbox и переезжать на Google Drive. Это решение вызвало череду приключений, которые мы совсем не планировали.

Для переезда с одного облачного сервиса на другой может быть куча разных причин: от риска блокировок (привет, Роскомнадзор) до потребности в каком-то принципиально новом функционале. В нашем случае причина была простой: мы сели, посчитали и поняли, что вместо 12 аккаунтов с безлимитным хранилищем у нас может быть 35 аккаунтов (то есть вся команда) — и всё это ровно за те же деньги.

Но фраза «сказано — сделано» не случайно встречается только в сказках. Не то, чтобы мы думали, будто перенос всех данных состоится по щелчку пальцев, но всё же на берегу представляли себе переезд куда проще. А зря.

Вот 6 важных моментов, которые мы открыли для себя в процессе смены облачного провайдера.
Читать полностью »

Обработка событий — одна из самых распространенных задач в области бессерверных технологий. Сегодня расскажем о том, как создать надежный обработчик сообщений, который сведет к нулю их потерю. Кстати, примеры написаны на C# с использованием библиотеки Polly, но показанные подходы будут работать с любыми языками (если не указано обратное).

Как не пропустить ни одного сообщения - 1Читать полностью »

Как нашего заказчика не хотел отпускать провайдер - 1

История довольно короткая, но смешная. С ней реально столкнулся наш заказчик. Началось всё в тот момент, когда один из провайдеров ИТ-инфраструктуры решил перевезти свой дата-центр. И предупредил примерно за полгода всех своих клиентов о трёхдневном даунтайме, но так тянул время и организовывал бюрократическую волокиту, что некоторые заказчики к миграции попросту не успели подготовиться.

Представьте: вы CIO. Бюджета на аварийную дублирующую площадку у вас нет. Старого оборудования тоже нет. Бизнес связан с предоставлением медицинских услуг, здесь каждый лишний час промедления стоит дорого: один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли, два часа — начнут страдать клиенты.

А теперь добивающий аккорд: переезд вам по факту осложняют, ставя в рамки и согласовывая каждый чих по месяцу. Потому что вы же много платите провайдеру, зачем вас отпускать?
Читать полностью »

Как мы организовали хранилище данных дешевле Amazon Simple Storage Service на 35% - 1

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

На втором этапе мы стали использовать объектное хранение, то есть хранение без иерархии каталогов. Все данные лежат на одном уровне, и каждый файл может быть доступен по своему ключу. Метаданные хранятся рядом с файлом. Для доступа используются простые команды уровня PUT — GET — MODIFY, есть возможность обратиться к каждому файлу по собственному URI, обеспечены лёгкость управления правами и лёгкость размещения самых разных данных и доступа к ним.

Минус данных решений — невозможность обращения к части (сегменту) файла, поэтому для приложений вроде баз данных такие хранилища не используются. Оптимальное применение — сложить туда картинки веб-сайта, файловую помойку, архивы или бэкап данных. На базе объектного хранилища мы построили свой S3 — систему хранения не очень часто изменяемых данных. С прямой совместимостью с Amazon S3.

А ещё классические протоколы доступа, использующиеся внутри компаний для файлового доступа (CIFS или NFS), не предназначены для обмена большими данными через сеть Интернет. Это ещё одна из причин, почему и зачем мы создали своё объектное хранилище.

Стояла задача сделать его не просто работающим отовсюду, но и дешёвым.
Читать полностью »

Отказоустойчивый кластер 3CX представляет собой два реплицируемых сервера АТС. Когда основной сервер выходит из строя, в работу включается сервер-реплика, минимизируя время отказа телефонии. В этой статье мы рассмотрим, как правильно конфигурировать отказоустойчивость АТС 3CX.

Лицензирование

Для использования отказоустойчивости вам потребуется одна лицензия Enterprise (ENT) или Professional (PRO). В лицензии ENT установлено время жизни (TTL) А-записи FQDN сервера 3CX в 5 минут. В лицензии PRO TTL А-записи установлено в 6 часов. Это значит, что в редакции PRO время аварийного переподключения IP-телефонов, клиентов 3CX, 3CX SBC и веб-клиента будет значительно выше.

Реализация отказоустойчивости

В 3CX используется принцип активного-пассивного кластера с репликацией конфигурации раз в минимум 24 часа. Основной (активный) узел выполняет обработку VoIP вызовов, а резервный (пассивный) узел мониторит активный хост. При выходе из строя активного хоста (независимо от причины), пассивный хост включается в работу примерно с того же состояния. Механизм определения выхода из строя активного хоста зависит от настроек на пассивном хосте и рассматривается ниже.Читать полностью »

Недавно мы рассказали, как меняется бизнес по доставке товаров — рост сегмента e-commerce ставит перед ним новые вызовы, со многими из которых позволяет справляться IaaS. Сегодня мы продолжим говорить о ритейле и посмотрим, кто и как использует виртуальную инфраструктуру.

Как IaaS помогает компаниям в сфере торговли: ритейл-кейсы - 1Читать полностью »

Кому НЕ надо переезжать в облако и почему - 1

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

Первая причина — кто-то уже успел купить железо. Очень часто бывает так, что в организацию приходит новый ИТ-директор и видит следующую картину: полгода назад его предшественник уже купил оборудование, оно ещё на поддержке и гарантии и будет работать года три стабильно. Естественно, в этой ситуации надо строить всё на нём просто по экономическим причинам.

Более сложная ситуация — это когда железо кто-то купил 20 лет назад (я сейчас не шучу), а оно ещё нужно. Точнее, нужно что-то, совместимое с ним. Я видел софт, который писался 15 лет назад, 20 лет назад и даже 25 лет назад. Тот, кто его писал, давно уже умер или не работает. А это, например, реестр в госструктуре на мейнфрейме или код банка, привязанный к микроинструкциям конкретной линейки процессоров или специфическим функциям ОС. Исходников нет. Документация только для эксплуатации. Если повезёт.

Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js