Обсуждение линковки серверов

[-=SJ=-]

Вы все так любите упоминать IRC но не принимаете во внимание что при всей внешней схожести этих чатов есть и куча различий. Например в CommFort существует система учетных записей для доступа к чату, в IRC такого нет у них лишь есть сервис NickServ который больше соответствует роли камеры хранения для ника, а не фейс контроля при входе в чат. Поэтому и разрывы связи (нетсплиты) между серверами в IRC не так страшны так как в это время каждый сервер живет своей жизнью куда могут подключатся пользователи, а при восстановлении связи все коллизии устраняются. Например если есть два пользователя с одинаковым ником одного из них кикнет.
Поэтому принцип IRC сети здесь не подходит, по крайней мере без серьезнейших модификаций.

[Maxim Mirgorodsky]

Большое спасибо за высказанные мнения.

Опишем свое видение линковки серверов в CommFort.

Цели, для которых реализуется линковка:
1) Снизить нагрузку на сеть.
2) Повысить стабильность работы чата.
3) Увеличить пользовательскую базу.

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

Камнем преткновения в линковке является синхронизация баз данных.

Синхронизация возможна только в случае дополнительного идентифицирования записей текстовым идентификатором сервера (как описал -=SJ=-). Плюсом такого подхода является возможность автономной работы серверов. Однако, реализация такого идентифицирования приведет к снижению удобства всех основных функций программы. Все пользователи, каналы, записи в списках ограничений будут идентифицироваться не только своим именем, но и дополнительным именем сервера. К тому же администрирование такой системы существенно усложнится. Обмен базами данных приведет к существенному росту нагрузки на сеть.

Наиболее целесообразным видится система Master-Slave, в которой с базами данных будет работать только один главный сервер. Минус такой системы - автономная работа slave-серверов в случае потери связи с master будет невозможной (потому что базы данных будут недоступны). Но целей снижения нагрузки на сеть и повышения стабильности работы (в следствие снижения нагрузки) добиться удастся. Причем без какого-либо влияния на функционал программы (клиентская часть вообще не изменится, с точки зрения пользователя дополнительных неудобств не будет).

Обсуждение продолжается, будем рады услышать любые мнения по этому вопросу.

[Glum]

так смысл линковки в автономной работе всех серверов.
Мне кажется реализовать можно так:
На главном сервере хранится основная база, на слэйве ее копия без права записи в эту базу, слэйв может писать в базу на основном сервере. В случае падения связи на слэйв сервере создается временная база для хранения вновь созданных учетных записей, а вся остальная информация берется из копии главной базы. В случае появления связи временная база удаляется, а юзеры из это базы переподключаются с предложением зарегестрироватся вновь. Репликацию для снижения нагрузки можно сделать в следующей форме. Главный сервер сам пишет копию базы в случае ее изменений на слэйв сервер, ну или посылает сигнал о том что в базе произошли имзенения и слэйв может ее скачать.
Хотел бы обратить внимание , что важным моментом является включение таких возможностей как запрещение приема картинок с другого сервера. Так как иногда важнее всего обеспечить просто связь , а картинки буду забирать канал. Тоже самое хотелось бы предложить реализовать и для разных интерфейсов, например для интерефейса который подключен к интернету прием картинок запретить.

[Kapacb]

Maxim Mirgorodsky

Сделайте полноценную голосовую связь или web-интерфейс

P.S. еще основные возможности не довели до ума, а за линковку беретесь

[hornet_ru]

Kapacb:
оффтоп.

Maxim Mirgorodsky:
Очень радует, что вы вышли на диалог по этому вопросу. Значит, надеюсь, лед тронулся.
Выскажусь и я по данному вопросу.

Цели, для которых реализуется линковка:1) Снизить нагрузку на сеть.2) Повысить стабильность работы чата.3) Увеличить пользовательскую базу.

На мой взгляд основные потребители данного ПО - средние по размеру домашние сети, где нужен легкий в настройке, администрировании и использовании клиент-серверный чат, с хорошим функционалом. Настройка IRC-сервера (+сервисов) задача для "админа"-новичка всё-таки далеко не тривиальная, да и IRC-клиенты (или рассказы "бывалых" о них ) формируют у простого обывателя стереотип, что "там надо знать программирование"
Наши кабельные домашние сети (любительские, а не те, коммерческие, которые прокладывают разные ISP оптоволокном) обычно состоят из нескольких территориально близких сегментов со сравнительно нормальной связью внутри себя, соединенных между собой кое-как (200-метровая воздушка полевым кабелем П-296, WI-FI и т.д.). Тоесть обычно имеют неоднородную по пропускной способности, а главное стабильности, линии связи между различными своими сегментами. И для тех, кому нужна линковка серверов, imho именно этот фактор является определяющим - необходимость повышения стабильности работы Commfort-a, когда разрыв связи между сегментами сети не оставляет половину пользователей локалки без чата вообще - ваш пункт №2.
Следующим важным пунктом, полагаю, является ваш п. №1 - "Снизить нагрузку на сеть". В контексте линковки снижение нагрузки будет достигаться за счет сегментирования трафика (особенно если передача файлов идет через сервер) - дело хорошее и нужное.
Что имелось ввиду под увеличением пользовательской базы - не совсем понял о чем идет речь. Тем более, если вы говорите, что:

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

В обсуждении протокола я бы кстати с удовольствием поучаствовал..

[kokish]

Kapacb:
оффтоп.

Maxim Mirgorodsky:
Очень радует, что вы вышли на диалог по этому вопросу. Значит, надеюсь, лед тронулся.
Выскажусь и я по данному вопросу.

Цели, для которых реализуется линковка:1) Снизить нагрузку на сеть.2) Повысить стабильность работы чата.3) Увеличить пользовательскую базу.

На мой взгляд основные потребители данного ПО - средние по размеру домашние сети, где нужен легкий в настройке, администрировании и использовании клиент-серверный чат, с хорошим функционалом. Настройка IRC-сервера (+сервисов) задача для "админа"-новичка всё-таки далеко не тривиальная, да и IRC-клиенты (или рассказы "бывалых" о них ) формируют у простого обывателя стереотип, что "там надо знать программирование"
Наши кабельные домашние сети (любительские, а не те, коммерческие, которые прокладывают разные ISP оптоволокном) обычно состоят из нескольких территориально близких сегментов со сравнительно нормальной связью внутри себя, соединенных между собой кое-как (200-метровая воздушка полевым кабелем П-296, WI-FI и т.д.). Тоесть обычно имеют неоднородную по пропускной способности, а главное стабильности, линии связи между различными своими сегментами. И для тех, кому нужна линковка серверов, imho именно этот фактор является определяющим - необходимость повышения стабильности работы Commfort-a, когда разрыв связи между сегментами сети не оставляет половину пользователей локалки без чата вообще - ваш пункт №2.

+1

[Maxim Mirgorodsky]

когда разрыв связи между сегментами сети не оставляет половину пользователей локалки без чата вообще

К сожалению, технически решение удовлетворяющее это требование пока не найдено.

На главном сервере хранится основная база, на слэйве ее копия без права записи в эту базу

Работа чата без возможности записи в БД слабо представляется. Нельзя будет создать каналы, изменять их настройки, администрировать чат (это самое важное), регистрировать пользователей, менять их учетные данные, публиковать объявления, оставлять сообщения при отсутствии пользователя-получателя. Врядли такая работа устроит администраторов и пользователей. При этом синхронизация баз повысит требования к каналу между серверами, как раз к тому что является слабым в случаях описанных в последних сообщениях.

[Rush]

Я не считаю что это сильно нагрузит каналы между серверами.
Сильнее нагружает постоянный поток картинок в канал, каждому пользователи, популярностью около 600 человек, когда в таком случае - пролетать будет одна картинка между серверами, нежели 600...

[Maxim Mirgorodsky]

Rush

Речь не об этом. Такого рода экономия будет в случае реализации линковки по любому варианту. Речь о том что при каждом подключении к master-серверу необходимо загружать все базы данных, а во время работы необходимо их синхронизировать. Но главная проблема не в этом, а в:

Нельзя будет создать каналы, изменять их настройки, администрировать чат (это самое важное), регистрировать пользователей, менять их учетные данные, публиковать объявления, оставлять сообщения при отсутствии пользователя-получателя.

[hornet_ru]

Я не считаю что это сильно нагрузит каналы между серверами.Сильнее нагружает постоянный поток картинок в канал, каждому пользователи, популярностью около 600 человек, когда в таком случае - пролетать будет одна картинка между серверами, нежели 600...

+1

Речь не об этом. Такого рода экономия будет в случае реализации линковки по любому варианту.

...и эта экономия лишней точно не будет.

Нельзя будет создать каналы, изменять их настройки, администрировать чат (это самое важное), регистрировать пользователей, менять их учетные данные, публиковать объявления, оставлять сообщения при отсутствии пользователя-получателя.

Такое категоричное "нельзя" говорить imho рано, мы же не обсуждаем уже какую-то конкретную схему/протокол.. Master-slave - это просто базисная схема, а как там всё будет или не будет синхронизироваться/администрироваться - зависит уже от её конкретной реализации.
Кстати вы зря так говорите, что "администрирование чата - это самое важное". Мы же не о разработке firewall-а разговариваем, тут надо правильно расставить приоритеты. Чат - это в первую очередь средство для общения и в домашне-городской локалке ставится для пользователей, а не для админа. И я считаю, что если будет выбор между всегда администрируемым односерверным комфортом и комфортом, поддерживающим линковку, но в котором при разрыве связи с мастер-сервером "нельзя будет создать каналы, изменять их настройки, администрировать чат, регистрировать пользователей, менять их учетные данные, публиковать объявления...", то выбор будет явно не в пользу первого. Ведь остаться в чате (на время разрыва связи между серверами), в котором можно хотябы просто пообщаться, - гораздо лучше, чем остаться вообще без ничего, любуясь красной иконкой в трее. Да и линковка - возможность ведь опциональная, хочешь - используй, не хочешь - не используй. Поправьте меня, если я не прав, но в том же IRC (которым наверняка тыкает каждый "продвинутый", когда речь заходит о линковке), если происходит netsplit (разрыв сети), то серверы, утратившие соединение с IRC-хабом, на котором расположены сервисы (chan-, nick-, memo-Serv...), остаются без этих самых сервисов.
С другой стороны, можно ведь попробовать и не убирать весь выше перечисленный функционал при разрыве связи. Бояться синхронизации баз можно было бы в случае, если бы серверы планировалось линковать по dial-up, но это же не наш случай. Почему вы говорите, что техническое решение пока не найдено? Периодическая синхронизация баз вас не устраивает как таковая или же вопрос просто в реализации, в деталях?

[ALFRED450]

интересно, а если взять к примеру как работают пиринговые сети (FlylinkDC++), ничего нельзя взять за основу? сервер - это хаб, клиент - соответственно клиент. Просто предложил )

[Glum]

когда разрыв связи между сегментами сети не оставляет половину пользователей локалки без чата вообще

К сожалению, технически решение удовлетворяющее это требование пока не найдено.

На главном сервере хранится основная база, на слэйве ее копия без права записи в эту базу

Работа чата без возможности записи в БД слабо представляется. Нельзя будет создать каналы, изменять их настройки, администрировать чат (это самое важное), регистрировать пользователей, менять их учетные данные, публиковать объявления, оставлять сообщения при отсутствии пользователя-получателя. Врядли такая работа устроит администраторов и пользователей. При этом синхронизация баз повысит требования к каналу между серверами, как раз к тому что является слабым в случаях описанных в последних сообщениях.

Максим вы вырвали из контекста одну фразу
я же писал

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

моржет я неправильно выразился, но возможно лигичнее даже чтобы все регистрации пользоватлей производил Master сервер, то есть Slave может только в случае изменения базы Masterом скачивать ее себе.

[Maxim Mirgorodsky]

моржет я неправильно выразился, но возможно лигичнее даже чтобы все регистрации пользоватлей производил Master сервер, то есть Slave может только в случае изменения базы Masterом скачивать ее себе.

В любом случае запись на slave сервере в базы вестись не сможет при автономной работы что приведет к:

Нельзя будет создать каналы, изменять их настройки, администрировать чат (это самое важное), регистрировать пользователей, менять их учетные данные, публиковать объявления, оставлять сообщения при отсутствии пользователя-получателя.

Такое категоричное "нельзя" говорить imho рано, мы же не обсуждаем уже какую-то конкретную схему/протокол.. Master-slave - это просто базисная схема, а как там всё будет или не будет синхронизироваться/администрироваться - зависит уже от её конкретной реализации.

Master-slave здесь ни при чем. Возможность автономной работы от master-сервера требует работы с базами данных. Что технически практически невозможно (возможно, но с недопустимыми ограничениями).

Кстати вы зря так говорите, что "администрирование чата - это самое важное". Мы же не о разработке firewall-а разговариваем, тут надо правильно расставить приоритеты.

Это индивидуально. Как правило, администрирование наименее важно в небольших домовых сетях (там и линковка-то не нужна), либо в корпоративных (там как правило необходимость в автономной работе не такая острая и надежность сети выше).

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

Как осуществить эту синхронизацию баз? Допустим, на одном сервере создали канал и дали ему определенные настройки, на другом (автономно работающем) создали канал с таким же названием и дали ему другие настройки. Серверы соединились друг с другом. Насколько корректно смешивать эти базы? В любом случае один из пользователей (осуществивших, допустим, настройку канала) окажется в полном ощущении что произошла какая-то ошибка. Решением могло бы быть дополнительное идентифицирование всех элементов всех баз данных идентификатором сервера, о недостатках такого метода я уже упоминал (http://www.commfort.com/rus/forum/viewt ... 172#p25172), они существенны.

[Rush]

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

[ZemAnt]

В данный момент накрылся роутер между подсетями.
На моей половине в чате 200 человек.
А вот вся другая подсеть находится без чата вообще.
Пофиг на ограничения. Сделайте, чтобы чат был и на той половине. Не важно какими средствами и нагрузкой на сеть. Это совершенно не имеет значения. Master-slave система вполне пригодна для этого.