Всем привет!

Мы будем проводить вебинар, посвященный организации моделирования крупных систем. В качестве примера большой системы можно привести комплексные системы управления (КСУ), боевые информационно-управляющие системы (БИУС), да и любые другие сложные математические модели, описывающие динамику крупной системы. Очевидно, что симуляции таких моделей занимают существенное вычислительное время. Ввиду специфики системного моделирования (модель является одним большим ОДУ) классические способы распределенных вычислений не являются применимыми. Поэтому была придумана технология распределенных симуляций High Level Architecture (IEEE Std 1516), про которую мы и хотим рассказать.

Компания Nokia, которой сейчас принадлежит подразделение Bell Labs, передала сообществу все права и копирайты на ОС — и переопубликовала под свободной лицензией MIT все четыре редакции и финальный релиз Plan 9.

Таким образом, пользователи могут распространять код системы и/или модифицировать его по своему желанию, в соответствии с условиями соглашения MIT. Поддержкой и продвижением системы займётся общественная организация Plan 9 Foundation.

Plan 9 писали с нуля, чтобы элегантно решить принципиальные задачи по работы в распределённой среде. Хотя эта система не получила такого широкого распространения, как Unix, но она по факту оказала большое влияние, породив несколько концепций, которые сегодня являются краеугольными камнями распределённых вычислений.

Уже не раз сталкиваюсь с подобной проблемой, когда люди приходят и просят помочь в решении проблем распределения нагрузки при внезапном возрастании аудитории их сайтов. Ну и самое трудоемкое в данной проблеме — это самописные CMS-подобные системы, которые иногда приходиться переписывать полностью.

Я не буду вдаваться в подробности распределения нагрузки, а отпишу лишь основные правила при соблюдении которых Ваша CMS будет легко масштабироваться.

Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

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

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

 

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

Задача:

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

Имеем:

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

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

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

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

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

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

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

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

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

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

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

Если посмотреть на развитие сетевых технологий, то можно заметить, что технологии движутся в противоположных направлениях.
С одной стороны- терминальные системы: повсеместное распространение нетбуков, гугловские и прочие онлайн-приложения, видео- и аудио- плееры онлайн, интернет- телевидение и радио. В общем, нетбук и широкий канал- вот все, что будет нужно.
С другой стороны- распределенные хранилища( торренты и всякие разные дисиплюсплюсы), распределенные вычисления( лекарства от рака и так далее, на которые мода прошла уже), тот же скайп, клиенты которого представляют собой пиринговую сеть.
С первого взгляда — диаметрально противоположные схемы, терминальная и равноправная. И у той, и у той есть свои преимущества и недостатки.
А может быть, возможно их объединить? Посмотрим на нынешние терминалы- с одной стороны, достаточно мощный процессор, поскольку для комфортного серфинга с флэшем и прочими сильверлайтами без этого не обойтись, причем по большей части ресурсы простаивают, достаточно большие винты (удобно, черт возьми), и обычно- безлимитный инет
Вполне себе ресурсы для пирингового обмена, как вычислительными, так и дисковыми ресурсами
Все идет к придумыванию софтины, которая по типу торрентов шарит ресурсы когда они не нужны и использование чужих ресурсов, когда это необходимо.
Например, на первых порах сервис в нете типа того же ютуба. Какая у него проблема? высокая нагруженность и вследствие- дороговизна для того, кто его поддерживает. Причем чем больше пользователей- тем тяжелее серверам
Представьте себе сервис, клиент которого при скачке ролика, сохраняет часть данных и когда этот же ролик смотрит другой человек- он скачивает не только с сервера, но и с компов других клиентов. Чем больше клиентов- тем меньше нагрузка на сервера.
Да, фантастично. Но разве не похоже что к тому и идет?

Довольно давно, собирая информацию по средствам параллельного программирования, наткнулся я на элегантный (другими словами сложно описать ощущения) язык Oz http://www.mozart-oz.org. Язык тогда показался мне достойным того, чтобы представить его Habraсообществу. И вот, у меня появилось время и причины это сделать.

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

send(socket; buffer; flag) = (if (flag == RECV) (recv(socket; buffer)) or (realsend(socket; buffer))).

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

Все давно уже знают о великолепной почте gmail.com и возможности хранить там более 7 гигабайт почты. Думаю, что также все знают о таких плагинах, как GMail Drive, который позволяет хранить в своем аккаунте файлы. Но, сейчас разговор не об этом, я хочу рассказать Вам о реально работающей системе, которая позволяет хранить неограниченное количество файлов на Gmail.com распределенно и с резервированием. Итак, задача, которую мне необходимо было решить еще три года назад, где хранить все увеличивающийся архив файлов, многие из которых я не буду использовать еще долгое время, так как к платным сервисам я отношусь скептически, то решено было сделать бесплатный. Выбор пал на gmail.com, который уже тогда предоставлял достаточно места для хранения почты.

Но, предстояло решить следующие задачи

1. размер письма gmail.com три года назад составлял 10 мегабайт
2. если загрузить на почту более 600 мегабайт за короткий период, почта блокируется
3. если выгрузить из почты более 600 мегабайт за короткий период, почта тоже блокируется

В качестве распределенного хостинга возьмем классический пример — создание блогосервиса на основе mu-Wordpress.
Задача — при ограниченном бюджете собрать отказоустойчивую (насколько это возможно) геораспределенную систему. Соответственно все оборудование берется в аредну в различных Дата-Центрах.
И тут следует сказать что не все Дата-Центры одинаково полезны. Высококачественные сдают сервер за 800$, а у низкокачественных вполне можно взять примерно такой же сервер в аренду уже за 100$. И именно эти особенности надо учитывать при создании геокластера.

Теперь о небольших хаках. По умолчанию в mu-Wordpress функция отдачи загружаемого контента сделана крайне неудачно — через PHP. Соответственно она была заменена на загрузку отдельным сервисом и вставкой загружаемого контента прямой ссылкой на статику.
Вторым хаком была модификация контроля кеширования. Кроме указаний кешировать статичные элементы дизайна был введен еще такой хак, который запрещал кешировать запись на время ее обсуждения (по умолчанию — 14 дней), а уже после она отдавалась с заголовком разрешающим кеширование. Кроме того хитро кешировались фиды RSS.
Финальным хаком стала система синхронизации БД — каждый INSERT/DELETE/UPDATE выполнялся на «соседе». Получился такой себе софт-рейд в контексте MySQL+PHP.

В интернет среде очень популярны онлайн приложения, в которых пользователи взаимодействуют друг с другом. Это игры, социальные сети, обучающие системы, корпоративные программы и другие. Количество пользователей интернет и как следствие интернет приложений неуклонно растёт. Чтобы обслуживать всех клиентов сетевой программы, а их может быть миллионы, требуется очень мощное программное обеспечение. Во время появления социальных сетей количество пользователей онлайн приложений выросло на несколько порядков. Но большую нагрузку испытывают не только веб сайты а и онлайн приложения (ММО игры, социальные приложения, корпоративные приложения и другие) а с приходом HTML5 и вовсе веб приложения станут интерактивными и потребуют обработку в реальном времени (чаты, голос, мгновенные сообщения, ММО игры).

Все больше появляется «облачных» проектов, предлагаемых различными компаниями. Так, Лаборатория Касперского где-то с месяц назад предложила собственное масштабируемое решение для борьбы с DDOS-атаками, Amazon запустил в работу вторую «облачную» программу, предлагая ну очень мощные облака для не очень богатых компаний, которые не могут купить собственный сервис. Ну, а компания Rackspace, о которой вроде положительно отзываются на Хабре, предлагает собственный open source проект на базе собственных мощностей для тех, кому хочется создать индивидуальное облако, отвечающее специфическим требованиям.

    В этой статье, мне бы хотелось рассмотреть один из необычных способов оптимизации приложения, а именно использование проекта Gearman для распределения задач. Gearman является фреймворком для построения таких систем. Примеров кода в статье нет, статья больше вводная, хоть и содержит в себе достаточно практической информации.

Этот текст является вольным переводом замечательного поста Kaushik Sathupadi на тему распределённых систем и существующих ограничений при их создании.

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

Часть №1: Идея нового сервиса — «Позвони, напомню!»

Вчера, когда ваша супруга в очередной раз оценила тот факт, что вы вспомнили о её дне рождения и подарили шикарный подарок, в голове всплыла забавная идея. «Хм, а ведь люди вечно всё забывают». А у вас просто блестящая память! Почему бы не сделать новый сервис, который позволит полностью раскрыться вашему таланту? С каждой мыслью об этой идее вам всё больше и больше она нравится. Вы уже даже придумали рекламу, которую можно было бы напечатать в газете:

«Позвони, напомню» — Никогда не забывайте, даже если вы не помните, что забыли!
Плохо себя чувствуете из-за того, что вы что-то забыли? Не переживайте. Помощь на расстоянии одного телефонного звонка!
Если вам нужно что-то запомнить, просто позвоните и сообщите нам об этом! Допустим, позвоните нам и сообщите телефон вашего босса. Забудьте про него. Когда вам нужно будет вспомнить его, перезвоните, и мы вам обязательно напомним.
Всего 3 рубля за звонок.

Типичное обращение в ваш сервис выглядело бы вот так:

Доброго времени суток.
На Хабре уже мелькала статья на данную тематику. Я хочу попробовать развить эту тему, и поделиться своими мыслями — как бы оно могло быть.
Итак, что же такое «туманные вычисления», или «fog computing». Это вычисления, основанные на распределенной инфраструктуре с негарантированной доступностью. Топологически — это ячеистая (mesh) сеть с динамической маршрутизацией, узлами которой являются сравнительно однородные по вычислительной мощности компьютеры.
В идеале, в эру «туманных вычислений» компьютеры-узлы находятся буквально повсюду — под ногами, в воздухе, на улице… Они настолько миниатюрны и дешевы, что их можно носить с собой килограммами. В наше время это скорее всего будет какая-то программная среда, консолидируюшая ресурсы множества виртуализованных «капель», и позволяющая на такой параллельной машине выполняться программам, написанным под кросс-платформенные среды — платформенная зависимость в таком окружении будет убийственна. Скорей всего, речь будет идти о Java, CLR, Python, JavaScript…