Рубрика «миграция»

Сам себе VDS-провайдер - 1

Если хотите пользоваться преимуществами VDS и при этом защититься от бессовестного оверсела, когда провайдер забивает ноду под завязку и не балансирует нагрузку — есть два пути.

Можно найти своего надёжного VDS-хостера. Или убить всех ситхов самому и сделать собственную звезду смерти (ноду) — заказать выделенный сервер и перенести туда все свои VDS. Ведь тогда мы точно будем знать, что все ресурсы только наши и всегда будут доступны. Да ещё и ставить сможем любую ОС, какую захотим, любой софт, который приспичит, а Битрикс будет радовать попугаями благодаря высокой частоте процессора. Кто знает, может даже начальство расщедрится и выпишет премию. Поехали!Читать полностью »

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

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

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

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

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

Срочный переезд с Amazon Web Services — истории двух клиентов - 1

Блокировки задели многие проекты, работающие для российского рынка. Ниже — история одного из срочных переездов нашего заказчика.

19 апреля они заметили блокировку одного из IP-адресов своего публичного сервиса частью провайдеров на территории РФ. 20 апреля ситуация усугубилась — вся подсеть стала недоступной. Это уронило тестовую среду, один из резервных каналов, частично нарушило работу почтовых серверов. Проблему удалось решить заменой IP-адресов, проксированием трафика через другие дата-центры.

Когда стало понятно, что всё это всерьёз и надолго (точнее, когда возник такой риск), один наш заказчик, компания Теко — международная процессинговая компания, решил развернуть инстанс в нашем облаке. Их CIO была важна большая федеративность сервиса, большее присутствие на территории РФ. Цитата:

«Облако в РФ даёт больше гарантий клиентам, что сервис не будет заблокирован РКН. Скорость, с которой нам предоставили ресурсы, была очень важна. Происходило всё достаточно быстро: первым делом мы добавили GEO dns для доступности сервиса на территории РФ, начали проксирование трафика через незаблокированные ДЦ. Медленная часть — федерация для БД».
Читать полностью »

Пока я ехал на работу и слушал новый альбом Дельфина, кто-то блокировал IP адреса Amazon и Google целыми подсетями. Роскомнадзор назвал недостоверной информацию о блокировании сайтов, не имеющих отношения к Telegram, но арендующих IP-адреса на тех же, что и мессенджер, сервисах, и создал горячую линию для противодействия распространения таких сообщений.

Поэтому я даже не догадываюсь, почему нам пришлось в течение вчерашнего дня помогать нескольким сервисам. Кого-то задело совсем немного, а кому-то пришлось мигрировать.

Если очень коротко — мы умеем быстро мигрировать из AWS. У нас совместимый API. Мигрировать клиентов из Google тоже можем. И в ближайшие недели мы готовы делать миграцию бесплатно и давать месяц на тесты в нашем облаке без договора и без гарантийного письма, просто по карточке компании. Не понравится — ничего платить не надо.

Ниже — howto для разных типов выгрузки ВМ с Амазона.
Читать полностью »

Это инструкция по миграции электронной почты из cPanel в Zimbra 8.0.x 8.x. Прежде чем сделать какие-либо изменения на сервере, необходимо совершить резервное копирование.

image
Читать полностью »

В современном мире, когда светлое будущее прочат микросервисам, кажется странным заниматься технологиями, которые помогают обновлять код без перезагрузки. Ведь микросервисы и контейнеры куда проще «убить» и создать заново. Тем не менее, мы продолжаем работу над системой живой миграции CRIU, и нам в этом активно помогают ребята из IBM. Почему? Попробуем объяснить.

image
Читать полностью »

При написании смартконтрактов важно помнить, что после загрузки в блокчейн, они уже не могут быть изменены, а следовательно, не могут быть внесены какие-либо улучшения или исправлены какие-то найденные ошибки! Все мы знаем, что ошибки есть в любой программе, а вернувшись к написанному пару месяцев назад коду мы всегда найдем, что там можно улучшить. Как же быть? Единственно возможный вариант – это загрузить новый контракт с исправленным кодом. Но как же быть, если на базе имеющегося контракта уже выпущены токены? На помощь нам приходит миграция! За последний год я попробовал много разных техник ее реализации, проанализировал применяемые в других крупных блокчейн проектах и что-то поизобретал сам. Подробности под катом.
Смарт контракты Ethereum: что делать при ошибке в смартконтракте или техники миграции - 1
Читать полностью »

Миграция в облако тесно связана с перемещением данных, настроек, приложений, операционных систем в виртуальный дата-центр облачного провайдера. Кажется, что это сложно и ненадежно, однако все больше компаний доверяют сервисы технологии IaaS. Например, в течение трех последующих лет 50% индийских организаций планируют переместить инфраструктуру в облако.

Рынок «идет» вверх — по прогнозу аналитического агентства Gartner, в 2017 году IaaS-сегмент вырастет на 36,8% и достигнет планки в 34,6 млрд долларов. Поэтому в сегодняшнем материале мы поговорим о том, на что компаниям обратить внимание, чтобы мигрировать инфраструктуру в облачную среду и избежать потенциальных рисков.

Как компании перенести свою инфраструктуру в облако и избежать ошибок - 1Читать полностью »

Операция “Миграция”: если ваша почта где-то там, а надо, чтобы была здесь - 1

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

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

Миграция инфраструктуры в «облако» по шагам: какие возникают сложности и где - 1

Мы довольно часто помогаем бизнесу заказчика переехать в «облако». Это совершенно нормальный запрос, и большая часть крупных компаний так или иначе переносит свои мощности. Около 80% случаев приходится на перенос уже виртуализированной инфраструктуры из «домашней» серверной в дата-центр, остальные 20% — это перенос прямо с железа (включая рабочие станции пользователей) в виртуальную среду плюс вынос самого вычислительного узла в «облако».

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