Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

2 Кластер серверов, взлетит ли?

2 Кластер серверов, взлетит ли?
Я
   Борода_Одмина
 
30.10.18 - 17:51
1. Взлетит100% (4)
2. Не взлетит0% (0)
Всего мнений: 4

Если к кластеру(1 физический) добавить второй в качестве резервного(в настройках так можно выставить) и повесить на этой второй еще и сервер лицензий. Оно взлетит?

В данный момент курю МАНы и что-то не очень понимаю. А протестировать возможности нет.
 
 
   DmitriyDI
 
1 - 30.10.18 - 17:53
(0) 1 база подключена сразу к двум кластерам сервера?
было так в одной конторе, работало, надо бы наверное на один кластер блокировку фоновых поставить.
   DmitriyDI
 
2 - 30.10.18 - 17:54
.

1. Взлетит
   Борода_Одмина
 
3 - 30.10.18 - 17:57
(1) да, бд на отдельной машине будет болтаться. По идеи если первый отваливается, то подхватить должен второй. В доках написано, что идет репликация соединений и при разрыве связи, клиенты цепляются к резервному.
   DmitriyDI
 
4 - 30.10.18 - 17:58
(3) там по другому было, надо было порт перепрописывать, чтобы к другому подключаться
   Cyberhawk
 
5 - 30.10.18 - 17:59
(1) Садись, два
   Cyberhawk
 
6 - 30.10.18 - 17:59
"По идеи если первый отваливается, то подхватить должен второй" // Бгг. Издание платформы какое?
   Вафель
 
7 - 30.10.18 - 18:00
нужно будет 2 комплекта лицензий
   DmitriyDI
 
8 - 30.10.18 - 18:01
(5) хочешь сказать 1 базу нельзя к двум (и более) кластерам подключить?
   Борода_Одмина
 
9 - 30.10.18 - 18:04
(6) последняя
   VitShvets
 
10 - 30.10.18 - 18:11
Есть очень неплохая статья на инфостарте, там это довольно подробно расписано http://catalog.mista.ru/public/907443/
 
 Рекламное место пустует
   Cyberhawk
 
11 - 30.10.18 - 18:30
(8) Нет, этого Я сказать не хочу.
Двойка тебе, во-первых, за саму такую мысль, во-вторых за неправильное понимание (или его отсутствие) озвученного в нулевом посте.
   nicxxx
 
12 - 30.10.18 - 18:33
(0) Про windows-авторизацию забудь в этом случае, если нет домена.

1. Взлетит
   DmitriyDI
 
13 - 30.10.18 - 18:35
(11) согласен) не правильно изначально понял мысль)
   Борода_Одмина
 
14 - 30.10.18 - 18:38
(10) (11)
1) спасибо за ссылку.
2) я так понимаю, что для создания реально отказоустойчивой связки нужно min 3 сервака.
   Борода_Одмина
 
15 - 30.10.18 - 18:40
(11) Когда уровень отказоустойчивости равен нулю, но есть хотя бы два центральных сервера, то при отказе одного из центральных серверов, те пользователи, сеансы которых к нему подключены, просто получат ошибку с предложением перезапустить 1С. Перезапустят 1С, подключатся ко второму центральному серверу, и все заработает.
   Cyberhawk
 
16 - 30.10.18 - 18:45
(15) В той статье терминология хромает
   Cyberhawk
 
17 - 30.10.18 - 18:58
Думаю, именно из-зя корявой терминологии статьи в ИС ты и думаешь, что "для создания реально отказоустойчивой связки нужно min 3 сервака". Двух достаточно.
   Cyberhawk
 
18 - 30.10.18 - 19:12
"чтобы было максимум две-три секунды торможения, и работа опять шла дальше, то выбивайте бюджеты на третий центральный сервер и устанавливайте уровень отказоустойчивости больше нуля. В этом случае с тремя серверами вы сможете перебрасывать сеансы пользователей без перезапуска"//

Чувачок (автор статьи) заблуждается.
Во-первых, с уровнем отказоустойчивости = 1 и двумя рабочими серверами в кластере (оба из которых центральные) при отказе любого из этих рабочих (центральных) сероверов кластер остается работоспсообным и пользователя спокойно продолжают работу. Т.е. никаких трех серверов не нужно.
Во-вторых, на выдачу ошибки (для пользователя) никак наличие трех серверов и какой-то там уровень отказоустойчивости не повлияет - это зависит только от того, выполняет ли пользователь запрос или открыта ли у него транзакция (и еще пара незначительных моментов). Т.е. никаких трех серверов для прозрачного переключения сеанса пользователя не нужно.
   Cyberhawk
 
19 - 30.10.18 - 19:13
Что там имеет в виду автор темы в нулевом посте под "резервным сервером" - не ясно
   Cyberhawk
 
20 - 30.10.18 - 19:21
Я, кстати, возможно догадываюсь, почему автор статьи ИС говорит, что нельзя при уровне отказоустойчивости = 0 обеспечить отсутствие ошибки на клиентах, которых обслуживал упавший рабочий сервер.
Потому что в документации (на ИТС) так написано, но только для примера с уровнем отказоустойчивоти = 1 (когда количество вышедших из строя _превышает_ этот уровень).
Но, во-первых, для уровня = 0 оно не работает так, как описано в доке, а во-вторых оно и для любого другого уровня не работает так, как описано в доке :)
   VitShvets
 
21 - 30.10.18 - 19:41
(20) Как я понял идею статьи, третий сервер нужен для централизации хранения сеансовых данных, журнала регистрации и полнотекстового поиска. А ещё четвертый, для лицензирования, его можно не покупать, но обязательно запретить клиентские подключения.
   Cyberhawk
 
22 - 30.10.18 - 19:54
(21) Не ясно, как ты это понял (откуда это следует). Думаю, ты что-то неправильно понял.
Никакой "централизации" в случае с более чем одним центральным сервером быть не может.
   unregistered
 
23 - 30.10.18 - 19:55
(22) > Никакой "централизации" в случае с более чем одним центральным сервером быть не может

Может речь о синхронизации? Уж она то должна быть по-любому.
   Cyberhawk
 
24 - 30.10.18 - 19:56
(23) Синхронизация конечно есть
   unregistered
 
25 - 30.10.18 - 19:56
Кстати говоря, что вы тут подразумеваете под словосочетанием "два кластера"? Реально два кластера или два центральных сервера в кластере? Что-то я запутался...
   Cyberhawk
 
26 - 30.10.18 - 19:58
(25) Это товарищ из (1) навел шухер, никаких двух кластеров автором темы конечно же не подразумевалось
   Cyberhawk
 
27 - 30.10.18 - 19:59
Гораздо интереснее лично мне (19). Уж не думает ли автор темы, что "резервный" может стоять в сторонке до тех пор, пока с "основным" все хорошо. Так не полуяится в 8.3, про группу резервирования забудь.
   VitShvets
 
28 - 30.10.18 - 19:59
(22) посмотри раздел про требования назначений функциональности.
   unregistered
 
29 - 30.10.18 - 20:00
Статью на ИС не читал, но думал, что для реальной отказоустойчивости количество центральных серверов в кластере должно быть УровеньОтказоустойчивости + 1.
   Cyberhawk
 
30 - 30.10.18 - 20:05
(28) Вроде понятен ход твоих мыслей (предлагаешь перечисленные тобою объекты требований назначать всегда только на какой-то один фиксированный рабочий сервер?), но тогда идея с тремя рабочими серверами ничем не лучше идеи с двумя, ведь выйти из строя в обоих случаях может этот "фиксированный" рабочий сервер.
   Cyberhawk
 
31 - 30.10.18 - 20:05
(29) Правильно
   unregistered
 
32 - 30.10.18 - 20:08
(28) А при чем тут требования назначения функциональности? Там вообще всё очень запутано. Если в кластере есть два центральных сервера, и при этом, например, требованиями назначено ведение журналов регистрации только на одном из них, то при выходе его из строя не совсем понятно что именно должно произойти с сервисом где ведутся журналы регистрации. Журналы начнут вестись на втором оставшемся сервере (не смотря на запрет требованиями)? Или вообще перестанут вестись? А что произойдёт с журналами, когда восстановится упавший сервер? И при любом раскладе консистентность этих журналов остаётся под вопросом - это будут отдельные никак не связанные журналы для просмотра которых в полном непрерывном виде придется пользоваться чем угодно, кроме самой 1С.
   Cyberhawk
 
33 - 30.10.18 - 20:12
(32) "при чем тут требования назначения функциональности?" // Да просто в статье на ИС автор утверждает, что надо три рабочих сервера, чтобы пользователи перетекали с одного надругой без ошибок на клиенте. А это конечно же не так. Вот и придумываем, почему он мог так утверждать )
 
 
   VitShvets
 
34 - 30.10.18 - 20:18
(30) (32) (33) Не обязательно пользоваться только запретами, есть же ещё приоритеты. Этот "третий" сервер назначаешь самым приоритетным по сеансовым данным, т.е. все сеансы будут жить там, т.е. при выходе из строя первого или второго (рабочих), получаем прозрачный и незаметный для клиента переход с сервера на сервер. Если падает третий, то  сеанс будет потерян, но при переподключении по приоритету (ввиду недоступности третьего) будет выбран первый или второй.
   unregistered
 
35 - 30.10.18 - 20:26
(34) Пусть так. Однако не ясно для чего всё таки непременно нужен третий сервер для уровня отказоустойчивости 1?
Ну будут у тебя сеансы пользователей по приоритетам прозрачно и незаметно скакать с отвалившегося сервера на оставшийся. Третий то тут при чем?
Или имеется ввиду задача сохранить уровень отказоустойчивости равный "1" даже в случае выхода из строя или останова на плановое ТО одного из серверов?...
   VitShvets
 
36 - 30.10.18 - 20:35
(35) В том то и дело, что третий нужен чтобы не скакали. Сеансовые данные живут себе спокойно на третьем, переключается только сервер "обработки"(рабочий).
(33) :) Ты искал консоль запросов, что умеет планы строить
https://its.1c.ru/db/files/1CITS/EXE/ExtReps/Unireps83/RequestConsoleManaged/RequestConsoleManaged.zip
   Cyberhawk
 
37 - 30.10.18 - 20:37
(34) Предложенная тобою схема ничем не выигрывает по сравнению с двумя центральными серверами, плюс ты не по назначению походу используешь словосочетание "рабочий сервер". Если два будут просто рабочими (не центральными), а центральный один, то это УГ, а не отказоустойчивость.
   Cyberhawk
 
38 - 30.10.18 - 20:39
(35) "Или имеется ввиду задача сохранить уровень отказоустойчивости равный "1" даже в случае выхода из строя или останова на плановое ТО одного из серверов?" // Эта задача и в кластере только с двумя центральными серверами решается
   Cyberhawk
 
39 - 30.10.18 - 20:39
Короче зачем третий так и не ясно, пока складывается впечатление что просто "для пущей надежности" )
   Cyberhawk
 
40 - 30.10.18 - 20:40
(36) "искал консоль запросов" // Благодарю. Давно такой архив видел на локальном диске, все думал что это за хня там внутри понаверчена ))
   VitShvets
 
41 - 30.10.18 - 20:42
(37) >> "рабочий сервер"
Не по назначению. Здесь под "рабочим" имею ввиду с точки зрения функциональности - что принимает клиентские соединения.
(39) Именно, для надежности.
   unregistered
 
42 - 30.10.18 - 20:42
(36) > Сеансовые данные живут себе спокойно на третьем

А он что - бессмертный? Ерунда какая-то. Только лишняя путаница возникает, когда пытаются в одном примере разобрать сразу и тему отказоустойчивости кластера и тему распределения нагрузки (различных сервисов) между рабочими серверами внутри кластера.
Смешались в кучу кони, люди,
И залпы тысячи орудий
Слились в протяжный вой… (с) Лермонтов М.Ю.
   VitShvets
 
43 - 30.10.18 - 20:47
(42) Пока жив третий, максимум что получит пользователь при падении первого или второго, так это несколько секундная задержка. Которую пользователь скорее всего не заметит. При падении третьего, самый печальный вариант, потребуется перезапуск.
   unregistered
 
44 - 30.10.18 - 20:52
(43) Мы видимо не понимаем друг друга. Зачем нужен третий сервер? Что изменится, если при уровне отказоустойчивости "1" у нас будет в кластере только два сервера (оба центральные)?  Пользователи перестанут прозрачно и незаметно перетекать с одного сервера на другой при выходе из строя одного? Нет, не перестанут.
   VitShvets
 
45 - 30.10.18 - 20:59
(44) Не перестанут, но в обычной жизни, когда живы все 3 сервера, первому и второму будет жить попроще.
   AmoreMe
 
46 - 30.10.18 - 23:04
Пятый год работаем в режиме отказоустойчивости (1), т.е. два кластера на каждом центральный сервер. Сейчас платформа 8.3.13 Мне нравится! На последней версии значительно улучшилась работа по балансировке нагрузки. Базы высоко нагруженные и пользователями и постоянными обменами (загрузка-выгрузка 24ч. в сутки). У начинающих возникнут проблемы даже на этапе развертывания такой системы однако дорогу осилит идущий. "100 лет" не писал на этом форуме... А да ещё, это похоже на зеркало, т.е. администрирование идет только на одном из кластеров все автоматом "переезжает" в зеркало (Завершение сеансов, регистрация баз, изменение свойств и т.д. но не настройки кластера и центрального сервера) Можно остановить один из серверов и посмотреть как будут мигрировать сеансы. Меня удивило, что в УЦ1С №1 (был грех) опытный преподаватель ничего не мог сказать о такой работе... Возможно он большой спец. в вопросах блокировок и прочего. Извините если не отвечу на какие-нибудь вопросы если они будут, но не отвечать на форумах это моё кредо. С уважением к сообществу!

1. Взлетит
   StanleyMarsh
 
47 - 31.10.18 - 00:11
(0) взлетит, только нужно сервер лицензий в оба кластера запихнуть, иначе при падении первого сеансы буду переходить, но лицензий на пользователей не будет.

1. Взлетит
   Cyberhawk
 
48 - 31.10.18 - 08:09
(43) Ты что-то явно напутал. Поведение на клиенте (задержка или падение) никак не зависит от количества серверов в кластере.
   Cyberhawk
 
49 - 31.10.18 - 08:09
(для придирчивых - в работоспособном кластере)
 
 Рекламное место пустует
   Cyberhawk
 
50 - 31.10.18 - 08:10
(46) "работаем в режиме отказоустойчивости (1), т.е. два кластера на каждом центральный сервер" // Чувак, не хочу огорчать тебя, но...
   Cyberhawk
 
51 - 31.10.18 - 08:11
(46) и (47) походу родственники товарища из (1) :)
   Борода_Одмина
 
52 - 31.10.18 - 10:22
(27) Терминология действительно запутанная, но потихоньку в нее въезжаю. На самом деле действительно надеялся на возможность поставить его в сторонку, на случай если основной сервер выпадает. По русски говоря есть самый простой вариант "Сервер 1с" <-> "сервер БД". Задумка была такая: поставить второй "Сервер 1с"(в "ролях" же можно выставить, что резервный) + "сервер лицензий". Если падает первый, то запускается(запускаем?) второй и он взамен подхватывает лицензии первого.
   unregistered
 
53 - 31.10.18 - 10:34
(45) > первому и второму будет жить попроще

Это вопрос не отказоустойчивости, а распределения нагрузки. Не следует смешивать эти два вопроса. Связаны они между собой очень и очень отдалённо. И уж тем более непонятно - зачем впаривать ради отказоустойчивости избыточное увеличение количества серверов, предназначенных для распределения нагрузки.
   Cyberhawk
 
54 - 31.10.18 - 10:34
"в "ролях" же можно выставить, что резервный" // Покажи на картинке, что ты имеешь в виду
   unregistered
 
55 - 31.10.18 - 10:39
(52) Конечная цель так и остается непонятной. Нужен отказоустойчивый кластер из двух серверов? Или всё таки нужен второй сервер, который выключен и будет включаться только при выходе из строя основного сервера.
Это две совершенно разные задачи. И решаются совершенно разными методами.
Начиная с того, что для отказоустойчивого кластера нужны серверные лицензии на каждый сервер.
   Борода_Одмина
 
56 - 31.10.18 - 10:52
   Борода_Одмина
 
57 - 31.10.18 - 10:58
(55) Конечная цель: сделать так, чтобы работа не встала колом. Собственно из-за каши в голове у меня нет понимая в решении.
   unregistered
 
58 - 31.10.18 - 11:09
(57) > цель: сделать так, чтобы работа не встала колом

Это нельзя назвать целью.
Цель - это, например, обеспечить бесперебойную работу при любых обстоятельствах. Тогда нужен отказоустойчивый кластер.
Или оговаривается максимально допустимое время простоя при сбое. Исходя из этого времени (от нескольких минут до нескольких часов) решения будут очень и очень разными. И одним только сервером 1С такие решения не ограничиваются. Тут и вопрос доступности, отказоустойчивости и резервирования серверов СУБД, и вопрос стратегии бекапирования/зеркалирования баз. А в довесок идут сервера инфраструктуры - DHCP, AD (если авторизация везде доменная) и пр.
Какое максимально допустимое время недоступности системы в случае локального армагедона у вас в сети? Каков минимально допустимый уровень качества сервиса в период восстановления? Допустимо ли, например, чтобы в случае сбоя основного сервера в течении какого-то времени (от нескольких часов до нескольких суток) вся система тормозила и подвисала, сидя на слабом резервном сервере, пока основной восстанавливают или заменяют.

Разные требования, разные цели, разные решения, разные деньги.
   Борода_Одмина
 
59 - 31.10.18 - 11:19
(58) вопрос доступности, отказоустойчивости и резервирования серверов СУБД, и вопрос стратегии бекапирования/зеркалирования баз. А в довесок идут сервера инфраструктуры - DHCP, AD (если авторизация везде доменная) и пр.  
в этом плане вопроса как раз таки и нет.

Речь скорее о бюджетности и некоторое время тормоза и подвисания допустимы.
   Борода_Одмина
 
60 - 31.10.18 - 12:13
(54) я, кажется, понял свою ошибку.
собственно на картинках 8.2, у меня же 8.3.

Есть такой нюанс: В отличие от платформы 8.2, в 8.3 нет групп резервирования кластеров. Но можно в один кластер запихнуть еще 1 ЦС.
   Cyberhawk
 
61 - 31.10.18 - 14:58
(56) А теперь перечитай (27)
   VitShvets
 
62 - 31.10.18 - 15:58
(48) Зависит же. Чем больше серверов, тем устойчивее система. :)
(53) Мы просто о разном. Я так то писал не формуле избыточности и другой теории, а как сделал бы, если бы имел SLA в 2-3 и более девяток. Но, как ты правильно пишешь в (58), это бессмысленно, если остальные системы не отказоустойчивы - СУБД, АД и прочее.
   Борода_Одмина
 
63 - 31.10.18 - 16:19
(61) собственно все и перечитал. Где чего не понимал, понял. Кое-что еще интересного для себя нашел. Собственно я и написал в (60) .
   ptiz
 
64 - 31.10.18 - 16:29
(35) "не ясно для чего всё таки непременно нужен третий сервер для уровня отказоустойчивости 1"
- в видео такие слова: "если выйдет из строя еще один - большинства не будет, кворума не случится, кластер откажет в соединении".
(я сам вообще не в теме, тем более про какой-то "кворум" :) )
   unregistered
 
65 - 31.10.18 - 16:47
(64) > если выйдет из строя еще один - большинства не будет

Ну как бы логично... Что, если из двух серверов выйдут из строя оба, то всё умрёт. Но исходя из этой логики нужно не 3, а 30 серверов. Вдруг 29 из них выйдут из строя...

Что должно случиться, чтобы два сервера упали одновременно или последовательно один за другим?... Как мне кажется, это что-то такое, что подразумевает маленький локальный армагеддон (всё рушится), когда работа какого-то одного конкретно взятого сервиса (1С) уже никого не волнует.

А если уж у вас три сервера, то почему не поднять уровень отказоустойчивости до "2"? Чего стесняться? Тем более в предложенном примере предлагается уронить два сервера из трёх....
   VitShvets
 
66 - 31.10.18 - 17:00
(65) :) В обычной жизни не решают только задачу надежности или только задачу распределения нагрузки. Делают некий баланс между стоимостью, надежностью и производительностью. Когда все три сервера являются центральными, с одной стороны возрастает нагрузка на репликацию, но с другой, какого-то внятного увеличения надежности не получаем, т.к. "Что должно случиться, чтобы два сервера упали одновременно или последовательно один за другим?". А потому дальше уже стоит играть распределением функционала. Тем самым мы снижаем нагрузку на центральные сервера, т.е. косвенно повышаем надежность решения в целом.
   Cyberhawk
 
67 - 31.10.18 - 17:03
(62) "Зависит же" // Похоже, ты невнимательно прочитал сообщение, на которое отвечаешь
   Cyberhawk
 
68 - 31.10.18 - 17:05
(66) "Когда все три сервера являются центральными, с одной стороны возрастает нагрузка на репликацию" // И здесь ты опять заблуждаешься. Является или нет рабочий сервер центральным, на репликацию никак не влияет.
   Cyberhawk
 
69 - 31.10.18 - 17:10
(ну, справедливости ради это влияет на репликацию реестра кластера, что конечно же ничтожно по сравнению с репликацией, осуществляемой между всеми рабочими серверами кластера)
   VitShvets
 
70 - 31.10.18 - 17:23
(67) > Поведение на клиенте (задержка или падение) никак не зависит от количества серверов в кластере.
Ответ Чем больше серверов, тем устойчивее система. Если падает сервер, что одновременно держит и сеансовые данные и обрабатывает клиентскую логику, то клиенту придется переподключаться. В общем случае, чем больше серверов, тем ментше шансов на сие совпадение. Ну при должной настройке требований естественно.
(69) Я не тестировал, лично моих данных нет. Я очень сильно сомневаюсь, что 1Сники писали бы просто так о падении производительности и необходимости соблюдать баланс. Цитирую, https://its.1c.ru/db/v836doc#bookmark:cs:TI000000035 :

Таким образом, можно вывести следующую формулу, связывающую количество центральных серверов в кластере и уровень отказоустойчивости: Количество центральных серверов = Уровень отказоустойчивости+1. При этом надо понимать, что буквальное следование этой формуле приведет к некоторому снижению производительности кластера, т. к. на синхронизацию реестра кластера будет тратиться некоторая часть мощности системы. При определении количества центральных серверов и уровня отказоустойчивости следует соблюдать баланс между отказоустойчивостью и приемлемым уровнем производительности кластера серверов, учитывая при этом характеристики оборудования компьютеров, входящих в состав кластера.
   Cyberhawk
 
71 - 31.10.18 - 17:46
Я хз, на что ты отвечаешь. Предлагаю тебе сформулировать мысль в виде "твое утверждение в такой-то части считаю неверным / еще каким-нибудь по такой-то причине".
   VitShvets
 
72 - 31.10.18 - 17:55
(71) вроде ставлю номера сообщений, на что отвечаю. Что именно не понятно? Хотя, забей, тема, имхо, себя исчерпала.
   Cyberhawk
 
73 - 31.10.18 - 17:58
Вот именно: номера вроде ставишь и они ведут на мои сообщения, и типа какой-то должен диалог складываться, но по факту ты дальше отвечаешь совсем на что-то другое
   VitShvets
 
74 - 31.10.18 - 18:10
(73) Ну или ты не понимаешь моего ответа. :)
   Cyberhawk
 
75 - 31.10.18 - 18:14
Соглашусь, что со стороны отвечающего, которому говорят, что он отвечает не на то, что думает, выгодно думать, что получатель ответа просто не понял ответ отвечающего.
Но могу тебя заверить, что твой ответ вроде как мне понятен, что и позволяет судить о том, что это ответ не на то, к чему этот ответ приложен.
Такие дела.
   VitShvets
 
76 - 31.10.18 - 18:26
А при чем тут выгода? Мы вроде тут не на базаре выгоду искать. Общаемся же, вопрос взаимопонимания. Ты пишешь примерно по одной "мысли на сообщение", я на эту мысль отвечаю. Тебе не понятно что я ответил и на какую именно твою мысль? Переспроси что именно не понятно, с цитатой. А отписываться "не на то ответил" или утверждать что всё понял, но не понял к чему... Ну как минимум не конструктивно, как максимум... Остановимся на как минимум.
   xXeNoNx
 
77 - 31.10.18 - 18:41
(17) и лицух 2комплекта, либо 3ий сервак-виртуалка с ключами
   Cyberhawk
 
78 - 31.10.18 - 18:50
(76) "Выгода" = "менее затратная" операция (акт мышления).
Ну т.е. мозгу выгоднее быстренько автономно дать объяснение происходящему, т.е. не вступая особо во взаимодействие с собеседником.

Давай предположим, что Я тебя не понял.
Правильно ли Я понял, что ты считаешь, что судьба клиента (упадет он или плавно перетечет с одного сервера на другой) зависит от количества серверов в кластере?
В чем проявляется эта зависимость?
Ты выше даешь примеры, показывающие влияние на _вероятность падения_, но какой в этих рассуждениях смысл, если поведение клиента затрагивается только тогда, когда произошел крах сервера, который обслуживает этого клиента?
   VitShvets
 
79 - 31.10.18 - 19:23
(78) > не вступая особо во взаимодействие с собеседником

Обоюдная история же. Проще отписаться, что ответ не на то сообщение, чем переспросить и/или признаться что не понял ответа. Ну да не суть, в контексте "Давай предположим, что Я тебя не понял.", проехали.

> ты считаешь, что судьба клиента (упадет он или плавно перетечет с одного сервера на другой) зависит от количества серверов в кластере?
Да.

>В чем проявляется эта зависимость?

Зависимость проявляется именно в снижении вероятности падения одного конкретного клиента. Совсем грубо, в условиях сферического коня в вакууме. Чем больше серверов в кластере, тем меньше вероятность, что падение конкретного сервера затронет именно этого клиента.

> какой в этих рассуждениях смысл, если поведение клиента затрагивается только тогда, когда произошел крах сервера, который обслуживает этого клиента?

Тут надо определиться, что значит "обслуживает". Если мы требованиями функциональности вытащим сеансовые данные на третий сервер(не центральный), то падение любого из центральных серверов не приведет к потере сессии клиента. Моя практика показывает, что рп-хосты падают чаще именно при обработке серверной части логики, кривой иногда. Т.е. вероятность падения сервера, что будет заниматься обслуживанием накладных расходов кластера минимальна. Т.е. вероятность вылета клиента в такой схеме стремится к нулю.
   unregistered
 
80 - 31.10.18 - 20:03
(79) Хмммм... Продолжение рассуждений в ключе "третий сервер - бессмертный". Почему при распределении вероятности падения какого-либо из трёх серверов предпочтения отдаются именно центральным? Почему ставится знак равенства между падением процесса rphost и падением сервера?
Или я чего-то не понимаю....
   Cyberhawk
 
81 - 31.10.18 - 21:08
(79) Ну так ты подтверждаешь, что Я правильно тебя понял, так?
К чему тогда пассаж "Проще отписаться, что ответ не на то сообщение, чем переспросить и/или признаться что не понял ответа"? Зачем мне признаваться в чем-то, чего нет? Не ясно...

Дале, отвечая "Да", ты отвечаешь - как Я и говорил выше - не на тот вопрос, который был задан (а вернее просто обсуждался). Про вероятность (ее рост или снижение) падения клиента Я ничего не говорил, тут и спорить не о чем - конечно чем больше серверов в кластере, тем вероятность ниже.
Но Я говорил исключительно про поведение клиента при падении рабочего сервера (одно из возможных двух) - и что это поведение никак не зависит от кол-ва рабочих серверов в кластере, если в нем есть хотя бы два центральных рабочих сервера. И даже не имеет значения, сколько конкретно рабочих серверов (один или более) "обслуживают" этого клиента (клиентский сеанс на сервере + клиентское приложение на хосте конечного клиента). Ты согласен с этим?
   Cyberhawk
 
82 - 31.10.18 - 21:11
Также не ясно, почему ты связываешь "сервер, что будет заниматься обслуживанием накладных расходов кластера" с вылетом клиента. Походу ты где-то заблуждаешься.
   ptiz
 
83 - 01.11.18 - 09:34
А поясните: в чем смысл делать некоторые серверы НЕцентральными?
Если падает центральный - падает всё. Тогда логично делать центральными (а не просто рабочими) все сервера. Разве не так?
   Cyberhawk
 
84 - 01.11.18 - 10:01
(83) Центральный обслуживает начало сеанса, т.е. принимает клиентские соединения. Как дворецкий или гардеробщик.
Рабочий сервер этого не может - он уже просто далее (в рамках своих рпхостов) обслуживает отданный ему сеанс (или "частичку" сеанса, если разнесено через ТНФ).
Во всем остальном разницы (вроде как?) нет.
Не делать рабочий центральным - ну, чтобы быстрее можно было исключить его из состава кластера, например. Хотя не особо быстрее по сравнению со снятием галочки, да)
   ptiz
 
85 - 01.11.18 - 10:12
(84) Вот именно, зачем лишать себя сервера, способного принять клиентские соединения?
   Cyberhawk
 
86 - 01.11.18 - 10:24
(85) Я видел как на рабочий сервер, не являющийся центральным, выносили полнотекстовый поиск и журнал регистрации, т.е. что-то некритичное. Ну типа разгружают остальные рабочие (центральные) серверы.
   unregistered
 
87 - 01.11.18 - 13:27
(83) > в чем смысл делать некоторые серверы НЕцентральными?

Несколько причин.
1. Сервер включается в кластер только для выполнения какого-то ограниченного круга задач (например только какие-то определенные регламентные задания, которые невозможно или нежелательно запускать на центральных серверах).
2. Увеличение количества центральных серверов приводит к росту накладных расходов на их синхронизацию. Зачем лишние тормоза, если отказоустойчивость не критична?

Не всем нужна отказоустойчивость. Для некоторых гораздо важнее иметь возможность распределения нагрузки между серверами.
   Cyberhawk
 
88 - 01.11.18 - 13:39
(87) 2. Не приводит. См. (68) и (69).
К сколько-нибудь заметному увеличению расходов на синхронизацию приводит _только_ повышение уровня отказоустойчивости.
   VitShvets
 
89 - 02.11.18 - 15:06
(80) Не бессмертный, но вероятность его падения существенно ниже. Именно из за выполняемых им функций. У меня есть живой пример, в кластере один центральный сервер, на котором живут клиентские подключение и выполняется вся логика, второй занимается обслуживанием втоиичных потребностей кластера типа фоновых заданий или лицензирования. Так вот за несколько лет работы второй сервер падал целый 1 раз. И то, не упал, а перезапустил рпхост, перезапустил некоторые регламенты и дальше всё стало жить прекрасно. Описываемый режим не тестировал, это  мои теоретические измышления.
   VitShvets
 
90 - 02.11.18 - 15:26
(81) > К чему тогда пассаж
Утомил, лень объяснять, проехали.

> Ты согласен с этим?
В такой формулировке, скажем так, почти.

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует