Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Основы масштабирования

Разработка веб-сайтов
Прочитав в этом блоге о балансировке на стороне клиента, решил опубликовать свою статью, в которой описаны основные принципы масштабирования для web-проектов. Надеюсь, хабралюдям будет интересно почитать.

Основы масштабирования



Масштабируемость — способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.ru

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

Читать дальше →
Всего голосов 68: ↑67 и ↓1 +66
Просмотры50.2K
Комментарии 49

Facebook открывает новые дата-центры

MySQL
Тысячи серверов в собственных дата-центрах Facebook с трудом выдерживают нагрузку. Каждую неделю на сайте регистрируется почти два миллиона новых пользователей вдобавок к имеющимся десяткам миллионов. Все они проводят на сайте в среднем по нескольку часов и загружают сотни страниц в день, что создаёт немалые проблемы для инженеров. Один из программистов Facebook рассказывает в корпоративном блоге, с чем приходится иметь дело.

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

Впрочем, инженеры Facebook эту ситуацию предвидели заранее и уже давно начали обустройство нового дата-центра в Вирджинии, который сейчас введён в строй. Судя по всему, это далеко не последний дата-центр компании Facebook.
Читать дальше →
Всего голосов 25: ↑24 и ↓1 +23
Просмотры881
Комментарии 28

Переезд с одного рабочего сервера на другой

Чулан

Задача:

перенести работающий проект с одного сервера на другой.

Имеем:

рабочий сервер, новый сервер сконфигурированный и настроенный для работы проекта.

Я не буду вникать в тонкости настройки сервера, так как это может быть в принципе любой сервер под любой ОС. Главное что бы у вас был полный доступ ко всей системе. Т.е. права администратора. А так же сервер должен быть готовым в любой момент принять посетителей. Т.е. должны быть настроены виртуалы, установлена СУБД, ВЕБ сервер и т.д.

Первый способ простой:

Вешаем на рабочем сервере страницу с надписью «Мы переезжаем, приходите завтра» и поехали!

Собственно лучше всего начать со скриптов. Было бы идеально, если бы у вас был SVN или CVS. В этом случае скрипты залить можно в один клик. В принципе по FTP так же можно легко залить, но если вам будет необходимо что-то подправить и быстро перезалить, то, возможно, будет немного проблематично в спешке залить все измененные файлы особенно если они разбросаны по разным директориям.

После заливки скриптов переходим к базе. Если ваша база не гигабайтных/терабайтных размеров, то можно попробовать сделать тестовую базу и залить туда весь дамп. Если дамп все-таки уж сильно большой, то можно залить только структуру и необходимые таблицы (что бы система «запустилась») в тестовую базу и тестировать на ней. Это нужно для промежуточного тестирования перед тем как открыть сайт для посетителей. Кроме тестовой базы создайте рабочую и залейте туда весь дамп но в настройках оставьте использование тестовой базы.

Виртуальный хост. Его следует настраивать так, что бы он мог работать с двумя разным доменами. Зачем? Опять же для тестирования. К примеру ваш сайт site.com сейчас закрыт, но вам же нужно убедиться что на новом сервере все будет хорошо? Вот для этого и нужен второй домен. Где его взять – это уже второй вопрос. Если у вас нет поддоменов – то можно на время добавить test.site.com и его прописать на новый сервер. Ну или же просто пропишите в хостах (в свой ОС) любой домен и это должно работать. Так же нужно заметить, что ваши скрипты должны быть правильно настроены для этого домена (если конечно они привязываются к доменам).

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

Если все прошло успешно – пробуйте зайти на тестовый домен. В этом случае при правильной конфигурации сайт должен работать корректно. Сделайте полную проверку системы – зарегистрируйте пользователя, проверьте отправку почты, аплоад файлов, работу служб, кронов, демонов и т.д. если все хорошо – переключите скрипты на реальную базу и можно менять ДНС (IP у реального домена). По мере того как будет проходить апдейт по ДНС серверам на ваш новый сервер будут прибывать все новые и новые посетители. Не забудьте на новом сервере убрать страничку с надписью. Она тут совсем ни к чему :)

Примерное время – от 30 минут до 3-4 часов (без учета времени обновления ДНСов)

Далее веселее…

Читать дальше →
Всего голосов 14: ↑9 и ↓5 +4
Просмотры773
Комментарии 9

Основы репликации в MySQL

MySQL
С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.
Читать дальше →
Всего голосов 72: ↑70 и ↓2 +68
Просмотры299.7K
Комментарии 44

Синхронизация двух серверов Apache + MySQL на FreeBSD

Системное администрирование
В данном обзоре я расскажу о реализации кластера состоящего из двух нод с резервированием популярной связки для веб сервера Apache + MySQL + FreeBSD (или любой Linux).
Читать дальше →
Всего голосов 56: ↑50 и ↓6 +44
Просмотры14.8K
Комментарии 49

Репликация в Postgresql 9.0

PostgreSQLРаспределённые системы
Доброго времени суток. Учитывая, что с момента релиза PostgreSQL 9 прошло уже некоторое количество времени — я решил пощупать одну из его новых функций — нативную репликацию. Как известно, новый механизм основан на пересылке XLOG`a от мастера к слейву. Одним из жирных плюсов можно назвать нормальную обработку ALTER`ов. Иными словами — администратор 9й версии может обойтись без Slony.
Читать дальше →
Всего голосов 58: ↑51 и ↓7 +44
Просмотры84K
Комментарии 42

Мультимастер репликация для firebird на python

Программирование
Из песочницы
Однажды появилась задача синхронизации двух баз данных, работающих под управлением СУБД Firebird. Ситуация вкратце такова.

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

Читать дальше →
Всего голосов 6: ↑4 и ↓2 +2
Просмотры8.2K
Комментарии 11

Когда триггерная репликация предпочтительнее встроенной в PostgreSQL

PostgreSQL
С 9.0 версии PostgreSQL есть встроенный механизм Master-Slave репликации (streaming replication).
Однако, с его появлением выбрасывать старые триггерные механизмы не следует.

В общем случае, если нам требуется нечто большее, чем одна абсолютно точная копия всего DB-сервера, то триггеры остаются с нами.

Примеры таких ситуаций:
  • Если требуется failover (т.е. останавливается Master и все запросы временно идут на Slave, а потом запущенный Master начинает догоняется до актуального состояния со Slave).
  • Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.
  • В проекте приходится использовать продуктовый «зоопарк» — т.е. Master и Slave имеют по какой-то причине разные версии, или же версии одинаковые, но ОС разной «битности».
  • В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).
  • Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.


Добавляйте в комментариях дополнительные варианты.

Примечание: Возможность построения failover задекларирована месяц назад в версии 9.1 под названием «Synchronous Replication». Однако, лично я пока ещё эксперименты не проводил.
Всего голосов 23: ↑20 и ↓3 +17
Просмотры3.3K
Комментарии 12

Watchdog для репликации в PostgreSQL 9

PostgreSQL
Приветствую. Хочу поделиться одним самописным костылём, авось кому-нибудь будет полезен.

Коротко о главном


Моделируем ситуацию: есть кластер PostgreSQL-серверов — мастер и n-реплик. Наступает черный день и одна(или несколько) реплик падает. Причины неважны — сдохла железка, уборщица перебила шваброй провод или НЛО временно зохавало серверную. Итог один — если реплика долго лежала, то сама она уже никогда не нагонится.
Читать дальше →
Всего голосов 25: ↑24 и ↓1 +23
Просмотры3.3K
Комментарии 8

MySQL репликация one-slave-multi-master

MySQLРаспределённые системы
Из песочницы

Предисловие.


Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер. Готового решения стандартными средствами не нашлось. Но так как проблема оставалась актуальной, со временем подоспел немного усложненный, но работоспособный вариант c использованием средств самой mysql.
Читать дальше →
Всего голосов 30: ↑29 и ↓1 +28
Просмотры12.2K
Комментарии 14

Основные тезисы конференции HighLoad++ 2011

Я пиарюсь
imageВ октябре 2011 года в Москве проходила ежегодная конференция разработчиков высоконагруженных проектов HighLoad++.
Решил поделиться с читателями основными тезисами с конференции. Поскольку вся информация открыта и доступна на странице конференции, решил что собрать все тезисы вместе будет не такой уж и плохой затеей. Сразу отмечу, что в отчёте не содержится детальной информации о каждом докладе — затронуты лишь ключевые моменты.
Итак, о чём говорилось на HighLoad++ 2011.
Читать дальше →
Всего голосов 32: ↑30 и ↓2 +28
Просмотры3.9K
Комментарии 2

Экстремальное тестирование streaming репликации PostgreSQL 9.1

PostgreSQL
imageВозникла задача внедрения streaming репликации Postgresql 9.1 на продакшене. А т.к. раньше с нею дела не имели, решили провести ее «эстремальное тестирование».

Для этого были запущены две виртуальные машины VMWare Player с Ubuntu Server. Установлена и настроена streaming репликация на Postgresql 9.1.
Читать дальше →
Всего голосов 28: ↑24 и ↓4 +20
Просмотры5.1K
Комментарии 17

Jelastic на Java Day SPB 2012

Jelastic
imageРады сообщить, что члены команды Jelastic Дмитрий Лазаренко и Марина Справа будут принимать участие в конференции разработчиков Java Day SPB 2012, которая состоится 10 февраля 2012 года. Мы приготовили для вас очень интересный доклад: «Один в поле не воин: как построить кластер GlassFish 3.1.1». Доклад состоится в зале «Stenberg» гостиницы Holiday Inn Московские Ворота (Санкт-Петербург, Московский проспект, 97а) на 17.45. Вы узнаете, как можно построить отказоустойчивый кластер серверов GlassFish. Будут рассмотрены такие вопросы, как регистрация серверов на балансировщике нагрузки, организация sticky sessions, репликация сессий между серверами, администрирование кластера, обновление приложений на кластере и дополнительное потребление ресурсов серверами в данной конфигурации. И конечно же увидите как это все работает на Jelastic.
Читать дальше →
Всего голосов 3: ↑3 и ↓0 +3
Просмотры1.1K
Комментарии 0

Отказ мастера в PostgreSQL-кластере: как быть?

PostgreSQL
Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.
Читать дальше →
Всего голосов 28: ↑25 и ↓3 +22
Просмотры7.3K
Комментарии 9

Эволюция архитектуры: от «самописных» сервисов к HandlerSocket

BadooВысокая производительностьРазработка веб-сайтов


Сегодня мы расскажем о том, как в Badoo изменился подход к проектированию нагруженных “key-value” сервисов. Вы узнаете, по какой схеме такие сервисы создавались нами несколько лет назад (использование БД в качестве репозиториев и специализированного демона как интерфейса к данным), с какими трудностями мы при этом столкнулись и к какой архитектуре в результате пришли, разрешив появившиеся проблемы.
Читать дальше →
Всего голосов 82: ↑76 и ↓6 +70
Просмотры19K
Комментарии 34

Репликация из OLTP в OLAP базу данных

«LifeStreet Media»MySQL
Из песочницы
Мой друг Роберт Ходжес на днях опубликовал статью про репликацию из OLTP в OLAP базу данных (а именно, из MySQL в Vertica), которую его компания построила на своем продукте Tungsten. Самое интересное, это преобразование данных, которое происходит в процессе репликации. Подход достаточно общий, и может быть использован и для других систем.

Обычный подход к репликации — это синхронный или асинхронный перенос бинарного лога с одной базы данных (мастер) на другие (слейвы). В бинарном логе строго последовательно записываются все операции, которые модифицируют данные. Если его «проиграть» на другой системе с той же начальной точки, то должно получиться точно такое же состояние данных, как и на исходной. «Проигрывание» происходит по одной операции или по одной транзакции, то есть очень маленькими кусочками.

Этот подход плохо работает с OLAP-специфичными, и особенно, колонко-ориентированными базами данных, которые хранят данные физически не по строкам, а по колонкам. Такие базы данных оптимизированы на запись, чтение и сортировку больших массивов данных, что типично для аналитических задач, но не на маленькие операции на единичных записях, потому что любая операция затрагивает много колонок, которые физически хранятся в разных файлах (а иногда и разных дисках). Хуже всего обстоит дело с изменением данных. Конечно, все базы данных поддерживают стандарт SQL и оператор UPDATE, но на физическом уровне он, как правило, транслируется в то, что обновляемая запись помечается как удаленная, а вместо нее вставляется измененная копия. Потом, когда-нибудь, «сборщик мусора» перетрясет таблицу и удаленные записи удалятся навсегда. Помимо плохой эффективности, отсюда следует, что частые удаления и обновления приводят к «засорению» базы данных, что снижает ее производительность в том числе и на чтение.

Роберт предложил, как мне кажется, новый, хотя и естественный подход к решению проблемы репликации данных для таких случаев. Бинарный лог преобразуется в последовательность частично упорядоченных множеств операций типа DELETE/INSERT для каждой таблицы, причем, так слово «множество» подразумевает, что «одинаковые» в некотором смысле операции достаточно сделать один раз. Поясню чуть подробнее.
Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Просмотры4.9K
Комментарии 8

Active Directory Replication Status Tool: Новая утилита от Microsoft для определения статуса репликации AD

Netwrix

Шон Дьюби, MVP в Directory Services, сделал обзор новой утилиты от Microsoft ADREPLSTATUS, предназначенной для определения статуса репликации. Как новая утилита работает и почему Вам все равно придется пользоваться старым-добрым REPADMIN — об этом Вы можете узнать подробнее под катом.
Читать дальше →
Всего голосов 12: ↑8 и ↓4 +4
Просмотры30.9K
Комментарии 3

Системы хранения данных: как медленно, но верно они отвязываются от железа

КРОК

Авария в первом дата-центре и автоматический перезапуск сервисов в другом

Виртуализация — одна из моих любимых тем. Дело в том, что сейчас можно практически полностью забыть про используемое железо и организовать, например, систему хранения данных в виде «логического» юнита, который умеет взаимодействовать с информацией по простым правилам. При этом все процессы между виртуальным юнитом и реальным железом в разных ЦОДах лежат на системе виртуализации и не видны приложениям.

Это даёт кучу преимуществ, но и ставит ряд новых проблем: например, есть вопрос обеспечения консистентности данных при синхронной репликации, которая накладывает ограничения на расстояния между узлами.

К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.

Но давайте начнём с самого начала — как работает виртуализация систем хранения, зачем оно всё надо, и какие задачи решаются. И главное — где конкретно вы сможете выиграть и как.
Читать дальше →
Всего голосов 35: ↑31 и ↓4 +27
Просмотры47.1K
Комментарии 42

Простая настройка репликации в PostgreSQL

PostgreSQL
Из песочницы
image
Возникла необходимость быстро и как можно проще организовать репликацию данных с сервера БД на резервный сервер. Простой и понятный способ на просторах Сети так и не нашелся, по этому пришлось по частям собрать информацию, которая и стала этой статьёй.

Решаемая задача. Исходные данные


Итак, имеем сервер БД, с которым работают клиенты, и резервный сервер, на который надо настроить репликацию с основной базы данных.
В моём случае используется PostgreSQL 9.2.1, который установлен на обоих серверах и поддерживает потоковую репликацию. Предположим что база данных на основном сервере развернута и работает, на резервном только установлен, но не настроен PostgreSQL. Для примера возьмем IP-адрес 192.168.1.1 за адрес основного сервера, IP-адрес 192.168.1.2 — за адрес резервного.
Как это сделать
Всего голосов 10: ↑7 и ↓3 +4
Просмотры9K
Комментарии 3

Резервная площадка в облаке с использованием vSphere Replication

CloudMTS
Резервная площадка в облаке

Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки – его можно успешно использовать в качестве резервной!

Читать дальше →
Всего голосов 15: ↑9 и ↓6 +3
Просмотры13.8K
Комментарии 8