Вопрос по оборудыванию - кластеризация: почему нет?

[UNSTOPBLE]

CPU : 4*Opteron 6176 (48*2.3GHz)

Немного работал с серверами (java application server). Тазики у нас были кульные, но столько ядер никто не ставил и не собирался ставить. Ограничивались машинами, у которых 8 ядер. Дальше наращивали мощность количеством машин в горизонтальном кластере. Я, конечно, не админ, но говорили, что много ядер - не панацея. А вот много машин - это дело. К тому же, более отказоустойчиво. Если падает сервер от нагрузки (возможно, я ошибаюсь, но три недели назад, когда ТВ внеплановое сделали, создалось впечатление, что сервера падали по недостаче памяти), то только один из кластера, а если их там 10, то это не слишком критично, к тому же, репликацией можно все перенести на другие сервера (если уровень загруженности позволяет). В крайнем случае, можно ребутнуть одну машину.

Конечно, возникает проблема распределения между серверами, но я верю, что она решаемая. На ядра же как-то распределение вычислений идет?

[ВсегдаОдин]

всьо круто , готов спонсировать?)

[UNSTOPBLE]

всьо круто , готов спонсировать?)

[GGumbo]

ну если учесть что в след. году интел планирует выпустить процессоры для серверов в 12 ядер...

[UNSTOPBLE]

ну если учесть что в след. году интел планирует выпустить процессоры для серверов в 12 ядер...

Автор: Павел Шубский | 13:51 | 28.08.09

"Несколько дней назад мы рассказывали о будущих 12-ядерных серверных процессорах AMD Opteron под кодовым именем Magny-Cours. Как оказалось, разработчики не ограничились рассказами об энергопотреблении – на конференции была показана вполне рабочая 4-процессорная серверная система. Сложно представить, но в сравнительно небольшом рэковом корпусе уместилось целых 48 вычислительных блоков (четыре 12-ядерных Magny-Cours)! К слову, будущие процессоры пропишут в новом разъеме Socket G34 с 1974 контактами, который придет на замену существующему Socket F (1207 контактов). Интересно, какого же размера будет процессор, чтобы уместить почти две тысячи контактов?"(С)

Никто не говорит, что 48 ядер - это 48-ядерный процессор. Это один тазик, с несколькими многоядерными процессорами.

[Hed1n]

Распределение мощности между ядрами разумеется есть. Совсем другой вопрос какое распределение здесь используется. Кластер это конечно круто... Но опять же смотря как делать. То что предлагаете Вы не есть отказоустойчивое решение ( Точнее оно более отказоустойчивое будет, но недостаточно) Ещё проблема в затратах вычислительной мощности, распределение между серверами... Не знаю на сколько здесь крутые админы, но учитывая что сервера лежат пару часов, они повесятся это делать. Тут будет 2 варианта, либо будет цепная реакция - упала одна машина, полетел весь кластер (у нас же он будет не просто считать что-то оп заданным алгоритмам ) Либо мощности будут расходоваться неэффективно, и в одно прекрасное ТВ кластер накроется медным тазиком. Хотя сама идея интересная, разнести всю эту кучу на два сервера (или три) было бы очень неплохо и надёжнее А в целом, Оптерон это конечно круто, но имеет ряд своих подводных камней которые всплывают очень не вовремя при таком количестве ядер... Везде есть плюсы и минусы, тут уже пусть админы мучаются как всё это дело организовать... не в обиду конечно, но у нас по ходу админы чёрного ящика, а не белого, поэтому сервер может вот так упасть на пару часиков... Может стоит просто одного белого админа завести ?

[KAZIK]

Братва не спорьте с нами с IT-шниками))))))темболее которые в ла2 играют)))вы ж всёравно в споре проиграете)))

Изменено 29 октября, 2012 пользователем KAZIK

[Hed1n]

ну если учесть что в след. году интел планирует выпустить процессоры для серверов в 12 ядер...

Ну и что? Количество ядер не такой уж и показатель. Вопрос как будут распределены вычисления и насколько качественной будет HT у них. Единственное что можно сказать, для сервера ла2 у интела более правильное решение чем у бульдозеров в любом случае

[UNSTOPBLE]

Тут будет 2 варианта, либо будет цепная реакция - упала одна машина, полетел весь кластер (у нас же он будет не просто считать что-то оп заданным алгоритмам ) Либо мощности будут расходоваться неэффективно, и в одно прекрасное ТВ кластер накроется медным тазиком.

1. От цепной реакции можно защититься грамотной балансировкой нагрузки. Допустим, у нас два сервера в класете. Если мы их нагружаем одинаково, то когда подходят к концу ресурсы у одного, то такая же ситуация и у другого. И как только упадет первый, запросы с него пойдут на второй и завалят и его. Ситуация качественно меняется, если нагрузку распределять, например, 60:40. Тогда при падении более нагруженного, у менее нагруженного будет запас ресурсов для обслуживания клиентов, которые переключились с первого сервера, пока тот ребутается. В критической ситуации, часть из клиентов можно и не переключать, а временно отказать в сервисе, но большая часть клиентов будет успешно работать в системе.

2. Чем больше система, тем менее эффективно используються мощности

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

1. Поднятие всей системы немного дольше выполняется, чем ребут одного сервера из кластера

2. Да, возможно и повесятся

Может стоит просто одного белого админа завести ?

Если причина лагов/падения серверов в утечке памяти/вычислительной мощности, то никакой админ без изменения конфигурации железа не поможет (имхо)

[Abaddon]

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

Падал из-за ошибки в jvm, а не от нагрузки как таковой.

[Admin]

Если уж подобная ошибка произойдет, то упадет все, и не важно из чего оно будет состоять.

Нужно еще разобраться, что конкретно вы хотите предложить - отказоустойчивое решение, или более быстрое? Проблем с производительностью на данный момент нет, даже на х7 сервере. А отказоустойчивость в данном случае не повысить никак. Если ошибка была в JVM, то сервер поднимается за 5-10 минут после того как мы об этом узнаем. А если отрубилось железо, то приходится вначале вручную восстанавливать базу данных из бэкапов, репликации и логов sql (в зависимости от ситуации). Даже репликация базы данных легко может поломаться, достаточно лишь отправить в базу некорректный запрос (недоработки mysql) и это можно несколько дней не замечать...

[UNSTOPBLE]

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

Падал из-за ошибки в jvm, а не от нагрузки как таковой.

Я бы поспорил на счет связности потоков. Например, как взаимодействуют части сервера, обслуживающие нормальный мир и инстанс зоны? То есть, я, конечно, не разбирался в реальном ла2 серваке, но логика подсказывает, что у этих двух частей взаимодействие только в пределах чата...

"Ошибка в jvm" - очень хорошая классификация ошибок То есть, имеете в виду, что в jvm есть баг?

[UNSTOPBLE]

Если уж подобная ошибка произойдет, то упадет все, и не важно из чего оно будет состоять.

Ноды кластера физически разные машины. Будь там хоть ошибка в jvm, хоть в операционной системе, хоть псих с топором, рубающий сервер в клочья, второй сервак от этого не упадет.

Нужно еще разобраться, что конкретно вы хотите предложить - отказоустойчивое решение, или более быстрое? Проблем с производительностью на данный момент нет, даже на х7 сервере.

А почему же тогда лагает, если проблем нет?

Поправьте, если я не прав, но источник лагов на х7 больно напоминает старый добрый java.lang.OutOfMemoryError, который выглядит так:

Система спокойно работает несколько часов. Ничего не предвещает беды. Память доходит до максимума, и выделяеть ее стает проблематично. Обработка всех клиентских запросов останавливается, и ждет. Ждет, пока под новые запрошенные объекты выделиться память. В это время у игроков "фриз". Срабатывает гарбадж коллектор, очищает чуток памяти, под обработку запросов есть место, ура все работает. Но проблема, сожравшая столько памяти, никуда не уходит, и через минутку-две "фриз" повторяется. Так несколько раз, пока объем памяти не заходит в тупик, и не выбрасывается вышеупомянутая ошибка. Ну и все летит к чертям (как летит - это уже отдельная история)...

Да, это не проблема производительности, но это и не ошибка jvm.

Мне кажется, я хочу предложить более отказоустойчивое решение.

А отказоустойчивость в данном случае не повысить никак. Если ошибка была в JVM, то сервер поднимается за 5-10 минут после того как мы об этом узнаем.

Если падает одна нода из-за любой ошибки, то другая спокойно обслуживает клиентов, пока вы 5-10 минут поднимаете первую. Не вижу отсутствия повышения отказоустойчивости

А если отрубилось железо, то приходится вначале вручную восстанавливать базу данных из бэкапов, репликации и логов sql (в зависимости от ситуации). Даже репликация базы данных легко может поломаться, достаточно лишь отправить в базу некорректный запрос (недоработки mysql) и это можно несколько дней не замечать...

С mysql (с этим гавном) никогда не работал, но Oracle, например, если вырубить кнопкой "пауэр", то ничего особо с бэкапов и репликаций восстанавливать не надо.

И странно как-то звучит, у вас отрубается железо сервера БД?

[Abaddon]

Я бы поспорил на счет связности потоков. Например, как взаимодействуют части сервера, обслуживающие нормальный мир и инстанс зоны? То есть, я, конечно, не разбирался в реальном ла2 серваке, но логика подсказывает, что у этих двух частей взаимодействие только в пределах чата...

Неправильная логика. Нормальный мир и инстанс зоны работают через один и тот же механизм. Иначе каждый инстанс стоил бы нам более сотни МБ памяти.

"Ошибка в jvm" - очень хорошая классификация ошибок То есть, имеете в виду, что в jvm есть баг?

Да, в jvm есть баги. Именно они являются основной причиной падений сервера. Гугли по «An unexpected error has been detected by Java Runtime Environment».

Ноды кластера физически разные машины. Будь там хоть ошибка в jvm, хоть в операционной системе, хоть псих с топором, рубающий сервер в клочья, второй сервак от этого не упадет.

То есть предлагается реализация с несколькими процессами, отдельными на каждый сервер. Если используется репликация, то они должны иметь полностью идентичный набор данных в памяти. То есть любое обращение в память надо синхронизировать и инициировать обновление на других серверах. Это потребует навскидку в миллион раз больше времени, чем обращение в оперативную память. Чисто теоретически можно переписать механизм видимости, разделив между нодами разные инстансы, но это огромный объм работы с примерно нулевым выходом. А делить как-то иначе в условиях открытого мира невозможно.

А почему же тогда лагает, если проблем нет?

Поправьте, если я не прав, но источник лагов на х7 больно напоминает старый добрый java.lang.OutOfMemoryError, который выглядит так:

Система спокойно работает несколько часов. Ничего не предвещает беды. Память доходит до максимума, и выделяеть ее стает проблематично. Обработка всех клиентских запросов останавливается, и ждет. Ждет, пока под новые запрошенные объекты выделиться память. В это время у игроков "фриз". Срабатывает гарбадж коллектор, очищает чуток памяти, под обработку запросов есть место, ура все работает. Но проблема, сожравшая столько памяти, никуда не уходит, и через минутку-две "фриз" повторяется. Так несколько раз, пока объем памяти не заходит в тупик, и не выбрасывается вышеупомянутая ошибка. Ну и все летит к чертям (как летит - это уже отдельная история)...

Да, это не проблема производительности, но это и не ошибка jvm.

OOME у нас последний раз был года три или четыре назад. А сборщик мусора у нас используется неблокирующий. Как правило это или ошибка в jvm, или дедлок, обычно в одной очень корявой библиотеке. Ее, кстати, таки заменили, и с тех пор еще не было проблем.

Мне кажется, я хочу предложить более отказоустойчивое решение.

Если падает одна нода из-за любой ошибки, то другая спокойно обслуживает клиентов, пока вы 5-10 минут поднимаете первую. Не вижу отсутствия повышения отказоустойчивости

Вам кажется. Не забывайте проблему синхронизации между нодами.

С mysql (с этим гавном) никогда не работал, но Oracle, например, если вырубить кнопкой "пауэр", то ничего особо с бэкапов и репликаций восстанавливать не надо.

И странно как-то звучит, у вас отрубается железо сервера БД?

Издержки агрессивной оптимизации и расположения сервера репликации на большом расстоянии. А что в этом такого странного?

[UNSTOPBLE]

То есть предлагается реализация с несколькими процессами, отдельными на каждый сервер. Если используется репликация, то они должны иметь полностью идентичный набор данных в памяти. То есть любое обращение в память надо синхронизировать и инициировать обновление на других серверах. Это потребует навскидку в миллион раз больше времени, чем обращение в оперативную память. Чисто теоретически можно переписать механизм видимости, разделив между нодами разные инстансы, но это огромный объм работы с примерно нулевым выходом. А делить как-то иначе в условиях открытого мира невозможно.

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

Как правило это или ошибка в jvm, или дедлок, обычно в одной очень корявой библиотеке. Ее, кстати, таки заменили, и с тех пор еще не было проблем.

Если речь идет о дедлоках на трансакциях, то тот же Oracle их выдает намного реже, потому что там не бывает локов на таблицу, в отличие от MySQL (я не эксперт по БД, но наш эксперт такое говорил).

Вам кажется. Не забывайте проблему синхронизации между нодами.

Зачем синхронизация? Пусть при падении одной ноды с нее выбросит пользователей, они смогут сразу же залогиниться на вторую. Без синхронизации.

Издержки агрессивной оптимизации и расположения сервера репликации на большом расстоянии. А что в этом такого странного?

НУ странно, что падает БД. У нас за полотора года БД ни разу не падала. А сервера с jvm - даже подсчитать не получится, сколько раз)

п.с. ну, в общем, я ответ где-то получил...