Привет! Дискламбер точно такой же, как и в предыдущем письме - не нравится - не читаем.
Итак, надеюсь, я развенчал (ну или хоть немного пошатнул) вашу веру в то, что "кластер - это это такая хрень, которая очень быстро все делает за нас". Но не дал ответа на вопрос, как же это все-таки можно использовать для пользы дела. Вот тут как раз пожелания большинства (а может быть и всех), пожалуй, сходятся. Я бы назвал это тремя словами, которые на первый взгляд могут быть непонятными: Никогда, Всегда и Быстро. Хотелка первая: Никогда. Помните Кин-Дза-Дза? "И даже ицелоп не посмеет меня бить по ночам. Никогда!". Желание пользователя сервера - чтобы данные не терялись никогда и ни при каких обстоятельствах. Однако, чудес не бывает, как я уже говорил. Если вы почитаете различные интересные статьи (например, вот тут http://www.linover.ru/detals_cluster.htm - специально нашел на русском), то, если опустить рекламу самих себя в этих статьях, вы столкнетесь с таким понятием, как "доступность", которое приводится везде, и вкратце означает величину, обратную времени простоя сервера. Считается очень просто - время*вероятность сбоя. Но при этом, все статьи (по крайней мере популярные) не рассказывают (или специально замалчивают?) некоторые детали. Вот вам пример (слегка притянутый за уши, но вполне реальный и более, чем вероятный). ************************************************************************* Лирика, можно пропустить, ниже будет резюме. ************************************************************************* ... Администратор Вася радостно потирал руки - наконец-то начальство вняло его мольбам и купило новенькое брэндовое железо. Настроить сервер (так как винтов было много, он сделал все, как советовали умные дядьки - 2 диска в зеркале на систему, отдельный диск на /tmp и своп, три (!!!) винта в зеркале на базу), поднять мониторинг упса для красивого выключения и запустить - заняло у него пару дней с перерывом на пиво и девочек. Cервер весело жужжал, подмигивая индикаторами дисков. На форуме игры появилась единственная новость "Ура! Мы обновили сервер и теперь максимальное количество игроков увеличилось до 5000!". ... Игрок Петя ходил на этого монстра уже больше сотни раз. Он знал все его уловки, знал в какой последовательности он начнет кидаться заклинаниями, знал, когда появится подмога в виде кучи ядовитых паучков. Один единственный раз за всю игру ему удалось выбить из этого монстра Бриллиантовый Меч Второго Уровня - который он очень выгодно продал на черном рынке за целых триста баксов!... ... Пятьсот миллионов лет назад, умирающая звезда послала последний привет окружающему миру. Поток высокоэнергетических частиц уносился прочь от того, что раньше было звездой, а сейчас представляло из себя часть великого Ничто, особую точку пространства-времени, которую через пятьсот миллионов лет приматы, вылезшие из океана, назовут Черной Дырой. ... Игрок Петя стоял в окружении злобных паучков, пробиваясь к главному Боссу Подземелья. Волшебные стрелы были на исходе, но Петя не сдавался. Его Лучник восьмого уровня мог продержаться еще минут пять - за это время он должен убить Босса Подземелья. Меткая стрела, усиленная заклинанием Проникновения попала в Босса и сразила его. Он упал и из его ослабевших лап выпал Бриллиантовый меч Пятого Уровня! Петя был вне себя от радости - сокровище лежало буквально в двух шагах от него! ... Поток высокоэнергетических частиц, последний вздох умирающей звезды, прошил Землю насквозь. Несколько тысяч частиц, потеряв почти всю свою начальную энергию, выбили лавину электронов в кристалле кремния, который был сердцем нового, недавно купленного сервера. Операционная система очень сильно удивилась, когда вместо ожидаемых данных в регистрах процессора обнаружился мусор. От обиды она рассказала консоли все, что она думает о процессоре и его регистрах и повесила табличку "не беспокоить! С такими пошляками, как этот процессор я не могу нормально работать!". ... "Server connection timeout!" - увидел сообщение игрок Петя. Соседи содрогнулись от крика в соседней квартире и того шквала нецензурных выражений, которые посыпались вслед за ним. Вероятность опять заполучить такую "шмотку" была никакой даже по представлению терпеливого Пети. ... "Хрень какая-то, прям мистика" - разводил руками сисадмин Вася "на ковре" у шефа. "Я пару раз мемтест прогнал - все было нормально. И память крутая - с ECC. Да и база не побилась - все нормально, сервер дальше работает без нареканий. Ну подвис ночью - мало ли, может бага какая в ядре, на выходных обновлю". ************************************************************************* Для тех кто пропустил лирику - имеем некие данные, результат которых зависит от генератора случайных чисел, которые пользователь увидел, но не подтвердил. Имеем сверхнадежный сервер (база не просто дублируется, а "триплируется" на три отдельных жестких диска (да хоть на пять). И имеем сбой, выход из строя (пусть и временный) некой детали (в данном случае - процессора), который ведет к полному откату транзакции, в которой были получены эти данные (вернее - в ее неподтверждении, что на практике одно и то же). Закономерно возникают два вопроса: 1) Считать ли ситуацию, при которой теряются такие данные, но не теряются другие, сбоем или нет? 2) Возможно ли избежать подобной ситуации при использовании высоконадежного кластера? Ответ на первый вопрос - по моему мнению - положительный. Т.е. сбоем это все-таки надо считать. Так как вместо ГСЧ могут быть какие-либо датчики (сейчас ДК меня будет бить за то, что данные в реальном времени пишутся в БД, но пусть попробует рассказать, что так делать низзя операторам мобильной связи, они данные со станции пишут напрямую в БД), которые выдали данные и забыли о них. Хотя, при здравом рассуждении, ответ на этот вопрос еще и будет зависеть от стоимости самих потеряных данных - неважно ведь, что время простоя сервера 30 секунд или 5 минут - за эти 30 секунд может многое произойти - скажем, абоненты того же сотового оператора наговорили 10 000 минут с каким-нибудь заокеанским оператором. Да-да, я знаю, вы мне сейсас начнете рассказывать, сколько стоит оборудование у НИХ. Поверьте, я знаю, сколько оно стоит. А вы подумайте о том же бедном игроке Пете, который убивал своего злобного монстра сотню раз ради одной виртуальной "шмотки", которая ему бы принесла ХХХ реальных денег. А если таких игроков у вас не одна-две тысячи, а десять-двадцать? Подсчитывать их потери по стоимости игрового черного рынка лучше не надо - они могут запросто перевесить стоимость игрового кластера целиком. Не верите мне - почитайте соответствующие исследования того же Ника Ая (Nick Yee), который ведет "проект Дедал" (http://www.nickyee.com/daedalus/) и прочие исследования игрового черного рынка игровых же вещей. Для нас - это запись в БД, для игроков - зачастую абсолютно реальные деньги, зачастую - побольше, чем зарплата админа в крутой компании. Плавно переходим ко второму - вопросу - а если у нас есть кластер, можем ли мы быть уверены, что такой ситуации не будет? Тут необходимо ввести оно понятие, которое тесно связано с ответом на данный вопрос. Почти цитируя тот же Linover: Единичная точка отказа (single point of failure, SPOF, SPF) - это компонент, отказ которого приводит к отказу всей системы (т.е. уязвимое место). Даже если мы и создадим супер-пупер кластер, каждый узел в котором продублирован (и прочее *ирован), для описываемой выше ситуации, ответ на такой вопрос - нет. И стоимость кластера тут вовсе ни при чем - разумеется, можно написать приложение (тот же сервер БД) в котором данные будут "раскидываться" по узлам кластера и даже при полной "смерти" одного из узлов, они все еще будут "живы" и Бриллиантовый Меч будет лежать в двух шагах от героя игрока. Самое уязвимое место (ну, если не считать игрока, конечно) - тут канал доставки данных. Точно такой же мат Петины соседи услышали бы и в том случае, если бы у него выключился свет, сгорел бы ADSL-модем и так далее. В том же случае, когда между "клиентом" и "сервером" можно создать два и более независимых канала, то самой уязвимой точкой уже становится клиент. Ну а тем, кто читает всю эту фигню с целью-таки получить ответы на поставленные по ходу этого текста вопросы, я специально напишу резюме более понятными словами: Создать устойчивый к сбоям оборудования кластер можно, при этом стоимость его будет определяться по формуле: (стоимость выбранного вами железа для одного узла)*количество узлов+стоимость "железной обвязки"+стоимость настройки. В случае если ОС не Linux или что-нибудь из бесплатных *нихов - не забудьте еще прибавить стоимость лицензий за софт и операционку - как правило, в этом случае, стоимость софта будет не очень отличаться от железа начального уровня. Потери данных же будут определяться всеми не подтвержденными на момент сбоя транзакциями. Если такой вариант вас, как Заказчика, устраивает - то вам потребуются ингридиенты формулы и грамотный системный администратор. Опыт показывает, что при стоимости самих серверов около 1к евро, стоимость создания трехузлового кластера, устойчивого к сбоям любых из двух узлов приблизительно равна 5-6к евро. Ну и зарплата админа, если уж быть точным, на период настройки и тестов кластера - около недели-двух, в зависимости от времени на тесты и опытности админа. При этом, все окружение абсолютно прозрачно для приложений, которые на этом самом сервере крутятся (я говорю о родных линксовых приложений, к которым, в частности, относится и наш любимый FB). Частично весь этот текст отвечает и на второй вопрос - Всегда. В случае, если мы создаем устойчивый к сбоям кластер, который Никогда не теряет незакоммиченные данные, мы в большинстве случаев, получаем еще и кластер, который доступен Всегда. Говоря математическим языком, условие "Никогда" является необходимым (но недостаточным) для кластера, удовлетворяющего условию "Всегда". А вот детальнее про методику построения "Всегда" и про "Быстро" я попробую рассказать позже, если меня не забросают камнями - от разочарования, к примеру. Ну и после некоторых консультаций с опытными Птицеводами. ;-) P.S. Ссылки на Linover я привожу не в качестве рекламы или с целью лишний раз поиздеваться над виндузятниками. Просто это первая вразумительная статья на русском (хоть и не лишенная рекламы), где описывается предметная область. Хотя опять-таки - описывается без подробностей и деталей - это вам придется либо спрашивать тут (может, кроме меня еще кто-нибудь интересуется данным вопросом), либо погуглить по ключевым словам "process mogration in cluster environment" и "cluster process checkpoint data loss". P.P.S. Ситуация с потоком высокоэнергетических частиц вовсе не надумана, как может показаться на первый взгляд. Ее "притянутость" в том, что именно такая причина сбоя очень маловероятна - чаще сбои происходят по вине электриков, устроивших КЗ, чем от вспышек Новых. Ну и к тому же для того, чтобы тысяча протонов (или других, взаимодействующих с материей частиц) вызвала лавину электронов в кристалле кремния должна выполняться целая куча условий. Но для иллюстрации сойдет :) -- Best regards, Sergey mailto:[EMAIL PROTECTED]
