[UserSide]

Запустился наш партнёрский проект - "UserSide Cloud"

http://www.uscld.com/

 

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

 

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

 

Т.е. основное отличие - п/о и данные устанавливаются и хранятся не на сервере клиента, а на серверах в облаке. Впрочем ввиду различного интереса различных органов это может быть преимуществом.

 

Прошу любить и жаловать.

 

По всем вопросам можно обращаться по адресу: support [at] uscld.com

Изменено 25 марта, 2015 пользователем UserSide

[FATHER_FBI]

Вот как тема создана вот так и код у вас написан "USERSIDE.Cloud - для небольших сетей"

Запустился наш партнёрский проект - "UserSide Cloid"

[UserSide]

Вот как тема создана вот так и код у вас написан "USERSIDE.Cloud - для небольших сетей"

Запустился наш партнёрский проект - "UserSide Cloid"

 

Спасибо за замечание.

[alibek]

Вот как тема создана вот так и код у вас написан

Код конечно жуткий.

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

Но это на самом деле мелочи и ерунда. Главное — что проект работает и работает нормально.

Я три раза начинал делать самописную систему, с правильной архитектурой, продуманной базой данных, большим потенциалом на расширение и т.п.

И ни разу не дошло до стадии «можно пользоваться без прямого влезания в базу данных».

А UserSide я использую, пользу система приносит.

 

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

[uscld]

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

Здравствуйте.

Каждому клиенту в облаке выделяется виртуальный сервер (VPS), на котором поднимается OpenVPN-сервер. На маршрутизаторах сети клиента поднимаются OpenVPN-клиенты. Благодаря тому, что OpenVPN достаточно неплохо справляется с маршрутизацией, при подключении маршрутизатора клиента к VPS на последнем автоматически будут созданы соответствующие данному маршрутизатору маршруты. Так что мониторинг сети работает достаточно хорошо. Точно так же работает личный кабинет для абонентов - через VPN.

[vop]

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

[pavel.odintsov]

Прикольная тема)

[FATHER_FBI]

А как быть с модулем us_peleng? Он же ресурсов жрем не меряно.

А в предлагаемой вами конфигурации 3200Мгц процессора и 3гб рамы наврят ли уживется UserSide+peleng.

[UserSide]

А как быть с модулем us_peleng? Он же ресурсов жрем не меряно.

А в предлагаемой вами конфигурации 3200Мгц процессора и 3гб рамы наврят ли уживется UserSide+peleng.

 

Зависимость линейная.

Чем больше коммутаторов в сети и MAC-адресов на них - тем сильнее нагрузка на модуль и на сервер.

 

Однако о ком мы говорим? Если это маленький провайдер - то там не будет объемов, а компании с 700-1000+ коммутаторов и 500К+ MACов - покупают полную версию и ставят на свои сервера.

[FATHER_FBI]

А как быть с модулем us_peleng? Он же ресурсов жрем не меряно.

А в предлагаемой вами конфигурации 3200Мгц процессора и 3гб рамы наврят ли уживется UserSide+peleng.

 

Зависимость линейная.

Чем больше коммутаторов в сети и MAC-адресов на них - тем сильнее нагрузка на модуль и на сервер.

 

Однако о ком мы говорим? Если это маленький провайдер - то там не будет объемов, а компании с 700-1000+ коммутаторов и 500К+ MACов - покупают полную версию и ставят на свои сервера.

Даже при 200 свичах и 10 копиях пеленгатора в кроне все равно он жрет не меряно. Особенно если в сети есть свичи из разряда "полудурок". Приходятся в конфиге userside-а увеличивать таймаут и соответственно увеличивать время запуска пеленгаторов.

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

Вот например самый последний баг в userside

Имеем свич Cisco. Пока все абонентмкие порты в switchport mode trunk система дергает fdb таблицу и соответственно работает автокомутация. Стоит перевести порты в switchport mode access, система уже не может дернуть fdb таблицу при любой схеме, будь то telnet или SNMP.

Изменено 25 марта, 2015 пользователем FATHER_FBI

[uscld]

А как быть с модулем us_peleng? Он же ресурсов жрем не меряно.

А в предлагаемой вами конфигурации 3200Мгц процессора и 3гб рамы наврят ли уживется UserSide+peleng.

 

Зависимость линейная.

Чем больше коммутаторов в сети и MAC-адресов на них - тем сильнее нагрузка на модуль и на сервер.

 

Однако о ком мы говорим? Если это маленький провайдер - то там не будет объемов, а компании с 700-1000+ коммутаторов и 500К+ MACов - покупают полную версию и ставят на свои сервера.

Даже при 200 свичах и 10 копиях пеленгатора в кроне все равно он жрет не меряно. Особенно если в сети есть свичи из разряда "полудурок". Приходятся в конфиге userside-а увеличивать таймаут и соответственно увеличивать время запуска пеленгаторов.

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

Вот например самый последний баг в userside

Имеем свич Cisco. Пока все абонентмкие порты в switchport mode trunk система дергает fdb таблицу и соответственно работает автокомутация. Стоит перевести порты в switchport mode access, система уже не может дернуть fdb таблицу при любой схеме, будь то telnet или SNMP.

 

Здравствуйте.

Все VPS мониторятся в Zabbix. Если будет ситуация, похожая на приближение к перегрузкам, то, для начала, будем искать источник этой проблемы в настройках оборудования в самой САП UserSide, так как на практике именно в этой части могут возникать проблемы чаще всего.

На тестовой конфигурации сейчас находится реальная сеть с > 4 тыс. абонентов, около 200 устройств на пеленге. Конфигурация VPS, как описано для версии "до 1000 объектов". Сервер справляется, перегрузок нет даже на таких объемах.

[FATHER_FBI]

А как быть с модулем us_peleng? Он же ресурсов жрем не меряно.

А в предлагаемой вами конфигурации 3200Мгц процессора и 3гб рамы наврят ли уживется UserSide+peleng.

 

Зависимость линейная.

Чем больше коммутаторов в сети и MAC-адресов на них - тем сильнее нагрузка на модуль и на сервер.

 

Однако о ком мы говорим? Если это маленький провайдер - то там не будет объемов, а компании с 700-1000+ коммутаторов и 500К+ MACов - покупают полную версию и ставят на свои сервера.

Даже при 200 свичах и 10 копиях пеленгатора в кроне все равно он жрет не меряно. Особенно если в сети есть свичи из разряда "полудурок". Приходятся в конфиге userside-а увеличивать таймаут и соответственно увеличивать время запуска пеленгаторов.

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

Вот например самый последний баг в userside

Имеем свич Cisco. Пока все абонентмкие порты в switchport mode trunk система дергает fdb таблицу и соответственно работает автокомутация. Стоит перевести порты в switchport mode access, система уже не может дернуть fdb таблицу при любой схеме, будь то telnet или SNMP.

 

Здравствуйте.

Все VPS мониторятся в Zabbix. Если будет ситуация, похожая на приближение к перегрузкам, то, для начала, будем искать источник этой проблемы в настройках оборудования в самой САП UserSide, так как на практике именно в этой части могут возникать проблемы чаще всего.

На тестовой конфигурации сейчас находится реальная сеть с > 4 тыс. абонентов, около 200 устройств на пеленге. Конфигурация VPS, как описано для версии "до 1000 объектов". Сервер справляется, перегрузок нет даже на таких объемах.

А какие устройства в этой сети? И опрашивает ли пеленгатор distribution свичи?

[uscld]

А какие устройства в этой сети? И опрашивает ли пеленгатор distribution свичи?

Устройства в основном access-уровня, distribution - нет. Есть еще несколько маршрутизаторов, на которых терминируются абоненты. Агрегация L2.

В любом случае пеленгер больше использует виртуальную память, чем процессор. Памяти 3 Гб для "до 1000 объектов" вполне хватает.

На самый крайний случай, если именно в Вашей сети имеются такие устройства, из-за которых пеленгеру не будет хватать ресурсов, и настройками пеленгера и ЮС исправить ситуацию не выйдет, то увеличить объем ОЗУ или добавить ядра процессора для конкретного клиента - технически не проблема совершенно.