Участник:MichaelBochkaryov: различия между версиями

Материал из ALT Linux Wiki
(легкий сервер, апдейт информации по sms-серверу)
 
(не показаны 2 промежуточные версии этого же участника)
Строка 21: Строка 21:
* Пакетная база: 4.0/branch с дополнениями
* Пакетная база: 4.0/branch с дополнениями
* Ядро: 2.6.27-ovz-smp
* Ядро: 2.6.27-ovz-smp
* SMS/WAP-шлюз [http://www.kannel.org Kannel]: (CVS от 21/07/2009)
* SMS/WAP-шлюз [http://www.kannel.org Kannel]: (CVS от 21/07/2009 + Alejandro's patches)
* SQLbox: 0.7.2
* SQLbox: 0.7.2
* monit
* monit
Строка 39: Строка 39:
* http://www.rattler.kiev.ua/DL/kannel-server-i586-20090913.iso
* http://www.rattler.kiev.ua/DL/kannel-server-i586-20090913.iso
* MD5SUM: 3d88c7bea228d0303017d140ce888495
* MD5SUM: 3d88c7bea228d0303017d140ce888495
* kannel: CVS 2009-07-21 + patches by Alejandro
* sqlbox: 0.7.2


== PostgreSQL Appliance ==
== PostgreSQL Appliance ==
Строка 87: Строка 83:
Страница проекта:
Страница проекта:
http://www.netstyle.com.ua/ru/open_source/server_lite
http://www.netstyle.com.ua/ru/open_source/server_lite
== Соображения по платформе ==
В этом разделе я попробую собрать свои соображения по серверной платформе, которую можно было бы применять в mission critical инсталляциях, таких как платформы телекоммуникационных операторов (собственно, эта часть меня интересует в первую очередь).
''Пока что все это исключительно в виде наброска - что в голову взбрело навеянного актуальными граблями и запросами.''
=== Общие требования ===
К общим будем относить требования, не связанные с функциональностью конкретной инсталлируемой системы, но имеющие значительный вес при выборе платформы.
'''Надежность''' - платформа не должна разваливаться ни по первому чиху, ни по десятому. В частности, это касается корректной отработки различных нештатных ситуаций, таких как рост нагрузки, некорректные данные, etc.
'''Безопасность''' - как минимум, должно быть понятно, каким компонентам мы можем доверять, а какие обязаны быть защищены внешними средствами.
'''Отказоустойчивость''' - критичные инсталляции должны обеспечивать работоспособность даже при физическом сбое отдельных систем. По сути, задача сводится к минимизации времени простоя при сбое программных или аппаратных компонент.
'''Управляемость''' - платформы должны быть расчитаны на внедрение в гетерогенную среду с централизованными системами управления (развертывание, конфигурация, мониторинг). В качестве примера можно привести возможность мониторинга по SNMP из какого-нибудь HP OpenView, общего для всей организации.
'''Масштабируемость''' - нежелательно, чтобы производительность решения жестко ограничивалась производительностью одного сервера. Идеальный вариант - линейная горизонтальная масштабируемость, когда для повышения производительности достаточно добавить еще один узел в кластер.
=== PostgreSQL ===
Так получилось, что меня лично эта СУБД устраивает больше других. Потому хотелось бы в серверных инсталляциях видеть решение, требующее как можно меньшего применения напильника.
'''Ориентировочные планы:'''
* переезд на ветку 8.4
* автонастройка под оборудование (pgtune)
* поддержка репликации для warm/hot standby (skytools?)
* распределение нагрузки и connection pooling (pgpool или pgbouncer)
* мониторинг (monit, pgsnmpd)
* анализ нагрузки (pgfouine)
* выбор/упаковка решения для ETL
* управление (phpPgAdmin)
Собственно, отдельные компоненты по большей части уже есть. Но нужно проработать типовые варианты применения и для них организовать законченные решения.
'''Предполагаемые use cases:'''
* выделенный сервер БД
* сервер БД совместно с другим ПО
* система для разработки
=== Perl5 ===
* переезд на 5.10 (впрочем, тут вопрос к at@)
* актуализация/упаковка фреймворков Moose, POE, Mojo, Catalyst, DBIx::Class
=== Мобильный мессаджинг ===
* доработка обвязки к Kannel (управление/мониторинг)
* обвзяка для быстрого развертывания OTA-платформ на Kannel
* обвязка для быстрого развертывания PPG (Push Proxy Gateway)
* упаковка Mbuni (MMSC и VAS MMS Gateway)
* приложения с типовой бизнес-логикой SMS-сервисов
=== Телефония ===
* OpenSER (OpenSIPS или Kamailio) для решений операторского класса
* Yate - тут под вопросом, но поддержка SIP-T может быть выгодна, если делать SS7-SIP шлюзы
* базовое решение для функциональности колл-центра
* интеграционные решения для CTI (Computer Telephony Integration)
* решение (out of box appliance) для конференц-серверов
* lksctp-tools - поддержка SCTP
=== NAS, SAN и другие ===
* DRBD
* iSCSI с обвязкой
* интеграция с heartbeat и/или openais

Текущая версия от 21:40, 24 февраля 2010

Alt linux team.png Этот участник состоит в ALT Linux Team под ником misha.

e-mail: misha@altlinux.org




Контакты

 

Место нахождения

Украина, Киев


Чем занимаюсь

  • Kannel (SMS/WAP Gateway)
  • Mbuni (MMSC, MMS VAS Gateway)
  • PostgreSQL
  • Perl packages (POE, Catalyst, etc)


SMS gateway Appliance

Решение для SMS-сервера на основе ALT Linux 4.0 branch с некоторыми дополнениями.

Особенности сборки:

  • Пакетная база: 4.0/branch с дополнениями
  • Ядро: 2.6.27-ovz-smp
  • SMS/WAP-шлюз Kannel: (CVS от 21/07/2009 + Alejandro's patches)
  • SQLbox: 0.7.2
  • monit
  • настройка времени по NTP
  • PostgreSQL 8.3.7
  • Максимально завершенная дефолтная конфигурация

Сборка от 08/12/2009

Старая сборка от 13/09/2009

PostgreSQL Appliance

Попытка организовать решение для развертывания сервера БД на основе ALT Linux и PostgreSQL. Основная задача - возможность с минимальными временными затратами получить функционирующий сервер БД.

Текущее состояние: альфа

Особенности сборки:

  • актуальная на момент сборки (28.06.2009) пакетная база 4.0
  • ядро 2.6.18 ovz-smp (последнее из бранча)
  • включенный "из коробки" ACPI
  • PostgreSQL 8.3.7

Посмотреть на результат можно здесь:

Net Style Server Lite

Легковесный серверный дистрибутив на основе 4.0/branch с поддержкой OpenVZ. У нас используется для развертывания серверных систем.

Особенности сборки:

  • пакетная база: 4.0/branch с дополнениями
  • ядро 2.6.27-ovz-smp-alt12 (chistyakov)
  • включенный "из коробки" ACPI
  • автоматическая настройка времени по NTP
  • локальный DNS-сервер
  • система мониторинга monit
  • убрана настройка пользователей
  • беспарольный аккаунт root

Грабли!

При тестировании под VirtualBox пришлось вручную подгружать модуль ide-cdrom, т.к. иначе не обнаруживается виртуальный CD-драйв.

Загрузка:

Страница проекта: http://www.netstyle.com.ua/ru/open_source/server_lite


Соображения по платформе

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

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

Общие требования

К общим будем относить требования, не связанные с функциональностью конкретной инсталлируемой системы, но имеющие значительный вес при выборе платформы.

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

Безопасность - как минимум, должно быть понятно, каким компонентам мы можем доверять, а какие обязаны быть защищены внешними средствами.

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

Управляемость - платформы должны быть расчитаны на внедрение в гетерогенную среду с централизованными системами управления (развертывание, конфигурация, мониторинг). В качестве примера можно привести возможность мониторинга по SNMP из какого-нибудь HP OpenView, общего для всей организации.

Масштабируемость - нежелательно, чтобы производительность решения жестко ограничивалась производительностью одного сервера. Идеальный вариант - линейная горизонтальная масштабируемость, когда для повышения производительности достаточно добавить еще один узел в кластер.

PostgreSQL

Так получилось, что меня лично эта СУБД устраивает больше других. Потому хотелось бы в серверных инсталляциях видеть решение, требующее как можно меньшего применения напильника.

Ориентировочные планы:

  • переезд на ветку 8.4
  • автонастройка под оборудование (pgtune)
  • поддержка репликации для warm/hot standby (skytools?)
  • распределение нагрузки и connection pooling (pgpool или pgbouncer)
  • мониторинг (monit, pgsnmpd)
  • анализ нагрузки (pgfouine)
  • выбор/упаковка решения для ETL
  • управление (phpPgAdmin)

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

Предполагаемые use cases:

  • выделенный сервер БД
  • сервер БД совместно с другим ПО
  • система для разработки

Perl5

  • переезд на 5.10 (впрочем, тут вопрос к at@)
  • актуализация/упаковка фреймворков Moose, POE, Mojo, Catalyst, DBIx::Class

Мобильный мессаджинг

  • доработка обвязки к Kannel (управление/мониторинг)
  • обвзяка для быстрого развертывания OTA-платформ на Kannel
  • обвязка для быстрого развертывания PPG (Push Proxy Gateway)
  • упаковка Mbuni (MMSC и VAS MMS Gateway)
  • приложения с типовой бизнес-логикой SMS-сервисов

Телефония

  • OpenSER (OpenSIPS или Kamailio) для решений операторского класса
  • Yate - тут под вопросом, но поддержка SIP-T может быть выгодна, если делать SS7-SIP шлюзы
  • базовое решение для функциональности колл-центра
  • интеграционные решения для CTI (Computer Telephony Integration)
  • решение (out of box appliance) для конференц-серверов
  • lksctp-tools - поддержка SCTP

NAS, SAN и другие

  • DRBD
  • iSCSI с обвязкой
  • интеграция с heartbeat и/или openais