Привет уважаемому сообществу!
В какой-то момент времени встала потребность перенести базу приложения на django с mysql на postgresql. Первые два захода на эту проблему были неудачными, но позволили разобраться с целостностью данных, искоренить проблемы для manage.py syncdb и manage.py migrate.
Читать полностью »
Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми, насчитывающая 190 миллионов пользователей.
Все данные хранятся в двух дата-центрах — европейском и американском. Некоторое время назад мы исследовали качество интернет-соединения у наших пользователей из Азии и обнаружили, что для 7 миллионов пользователей наш сайт будет загружаться в 2 раза быстрее, если мы переместим их из европейского дата-центра в американский. Перед нами впервые встала задача крупномасштабной миграции данных пользователей между дата-центрами, с которой мы успешно справились: мы научились перемещать 1,5 миллиона пользователей за один рабочий день! Мы смогли перемещать целые страны! В первой части мы подробно расскажем о поставленной перед нами задаче и о том, какого результата мы достигли.
Читать полностью »
В связи со сменой сервис провайдера и переездом из одного датацентра в другой возникла необходимость миграции контроллеров домена леса и трех его доменов. Решено было поднять свежие машины в новом датацентре, мигрировать на них текщие AD DS роли, после чего утилизировать старые серверы домена.
Наш лес состоит из трех доменов: одного корневого (в котором ничего нет, кроме домен котроллеров) и двух дочерних доменов (там находится весь функционал). Основой разделения доменов служило разделение обязанностей между ИТ командой компании и ИТ специалистами сервис провайдера. В каждом домене существует по два домен контроллера: первый на реальном железе, второй в виде виртуальной машины. Функциональный уровень леса – Windows 2008 R2. Операционная система установлена на всех серверах та же. На каждом сервере имеется DNS сервер с интегрированными в AD зонами.
Ниже я в общих чертах опишу весь процесс.
Читать полностью »
В жизни любого хостинг-провайдера перенос клиентов между собственными серверами – задача достаточно обыденная. Для подобного переноса может быть множество причин: начиная с планового апгрейда оборудования или софта и планового «перераспределения» клиентов в связи с неравномерной загрузкой серверов, заканчивая срочным перемещением пользователей в случае аварий.
Реже в жизни провайдеров возникают задачи по переносу клиентов от другого провайдера shared-хостинга.
Причиной такого переноса может быть как «усталость» хостера-«донора» от подобного высокотехнологичного бизнеса, так и вынос услуг хостинга на аутсорсинг в более крупную хостинг-компанию в случае, если оказание этих услуг не является для решившейся на перемены организации профильным бизнесом (например, если речь идет о веб-студии, интернет-провайдере, провайдере сервис-услуг и т.д.).
Количество потенциальных проблем при переносе клиентов между разными провайдерами намного больше, нежели при переносе внутри одного хостинг-провайдера. Это связано с тем, что инфраструктура «старого» и «нового» провайдера может значительно отличаться:
Читать полностью »
Авария в первом дата-центре и автоматический перезапуск сервисов в другом
Виртуализация — одна из моих любимых тем. Дело в том, что сейчас можно практически полностью забыть про используемое железо и организовать, например, систему хранения данных в виде «логического» юнита, который умеет взаимодействовать с информацией по простым правилам. При этом все процессы между виртуальным юнитом и реальным железом в разных ЦОДах лежат на системе виртуализации и не видны приложениям.
Это даёт кучу преимуществ, но и ставит ряд новых проблем: например, есть вопрос обеспечения консистентности данных при синхронной репликации, которая накладывает ограничения на расстояния между узлами.
К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.
Но давайте начнём с самого начала — как работает виртуализация систем хранения, зачем оно всё надо, и какие задачи решаются. И главное — где конкретно вы сможете выиграть и как.Читать полностью »
Некоторые старички Хабра до сих пор помнят мой пост «Хотите ли вы коворкинг в Тайланде?». За 3 года в Чиангмае произошли большие и интересные перемены: здесь появилась критическая масса инициативных русских ИТ-специалистов, которые жаждут перемен.
Недавно в Чиангмае русскими был организован CNX Business Club — общественная организация, бескорыстно помогающая специалистам в области IT & Media обосноваться в городе, претендующем на звание одного из IT-центров Юго-Восточной Азии. Расскажу поподробнее, чем привлекателен город.Читать полностью »
Задача.
Перенести существующий аппаратный сервер с FreeBSD 8.2 архитектура i386 и файловая система ufs в виртуальную среду VMware ESXEi 5.0.0
Если Вы апологет или евангелист этого производителя, пожалуйста не читайте дальше, на хабре есть множество других интересных статей.
Читать полностью »
В этой статье я расскажу об одном из средств обеспечения версионности схем и управления миграциями БД — библиотеке Flyway. С поблемой версионности схемы базы данных рано или поздно приходится сталкиваться разработчикам любого приложения, опирающегося на СУБД. Увы, иногда эта проблема принимается в рассмотрение слишком поздно — например, если вопрос о внесении изменений в структуру базы встаёт, когда приложение уже находится в эксплуатации. Но и на этапе разработки контроль схемы базы данных причиняет не меньше проблем, чем все прочие аспекты версионности приложения: в отсутствие чёткой системы управления миграциями локальная, стендовая и эксплуатационная базы могут быстро «разъехаться», не предоставляя при этом никакой информации относительно своего текущего состояния.
Сейчас мы будем переносить физические и виртуальные серверы со всеми запущенными на них службами и прикладным ПО и аккуратно обходить все разложенные грабли.
Сразу: я считаю наиболее эффективным и незаметным для конечных пользователей вариант миграции, который проходит по принципу масштабирования в облачную инфраструктуру с последующим отказом от физического оборудования. Но это идеальный вариант, поэтому говорить будем о мгновенном или очень краткосрочном переезде.
