16 ноября, пятница 21:33
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

POS SSL stunnel

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • POS SSL stunnel

    Добрый день. Прошу поделиться практическим опытом по stunnel.

    Тема подключения POS-терминалов через интернет уже неоднократно здесь обсуждалась, хотелось бы прояснить некоторые моменты.
    В нашем случае ПО POS-терминала включает поддержку SSL. В качестве SSL-сервера предполагается использовать x86 linux-сервер с stunnel.

    Вопрос собственно в следующем - каковы примерные показатели производительности такой схемы? Сколько одновременных соединений позволяет поддерживать stunnel? Есть ли возможность настройки stunnel по подобию httpd, когда одновременно запускается несколько экземпляров демона, что позволяет увеличить доступность сервиса.

    Все-таки лимит соединений - это больше ограничение сервера (объем ОЗУ, производительность процессора) или же программное ограничение (ОС + самого stunnel)?

    В одной из тем написано, что stunnel под linux'ом тянет около 270 одновременных соединений - насколько это соответствует действительности?

    Спасибо.

  • #2
    Линукс линуксу рознь, это не вантуз, который выходит из корпорации Майкрософт весь одинаковый. Всё очень сильно зависит от того, как оно собрано и поставлено, тем линукс и силён. Одно дело - дистибутив из коробки, рассчитанный на некий среднеофисный десктоп пополам с малолетним геймером-меломаном, другое - специализированная сборка под конкретный процессор и конкретные приложения.

    У нас, например, есть такой серверочек NSG-1000/GW для нашей сиcтемы uiTCP - довольно скромненький, на одном Атоме 330. Внутри uiTCP идёт тот же SSL, так что вычислительная нагрузка на шифрование такая же, плюс ещё сколько-то на гарантированную доставку пакетов. Некоторые заказчики его и используют просто как STunnel. Так вот нагрузить его на 100% пока не удалось ни нам, ни нашим заказчикам, но по оценкам - сессий на 500 его точно должно хватать. Даже намного более скромная NSG-700 (ARM 180 МГц, 64 МБ RAM), которая вообще-то считается устройством доступа, тянет десятки сессий.

    Основное ограничение - скорее по производительности процессора (опять же, если система многоядерная - то как собрано ядро? как собрана SSL? с поддержкой SMP или нет?), тут счёт идёт на мегабиты/с. Мегабит - это, грубо говоря, 100 POS-ов, передающих/принимающих на 9600 Кбит/с. Так что оценка 270 _одновременных_ сессий, в принципе, реалистична хотя бы по порядку величины.... Чтобы получить отсюда максимальное число POS-ов в системе, разделите это на долю времени, в течение которого POS реально передаёт/принимает данные, по отношению к полному времени обслуживания клиента (~0,01-0,1).

    Память ничего не лимитирует, её можно поставить или много, или очень много (при соответствующей цене мамки). Плюс неограниченный своп - опять же, вопрос быстродействия, но опять же для POS-ов несущественный.

    Если есть практический интерес - прошу в личку, ибо коммерческие вопросы здесь обсуждать не подобает.
    http://www.nsg.ru

    Комментарий


    • #3
      Сейчас интересует поднятие SSL-сервера именно на универсальном оборудовании (обычный современный стоечный сервер), которое, уже в случае значительного роста SSL-клиентов, будет заменено на какое-нибудь специализированное.

      Вопрос как раз в том, когда наступает этот порог...

      Может кто-нибудь знаком со средствами стресс-тестирования SSL-сервера (stunnel)?

      vyurin, а цифру в 500 сессий на NSG-1000/GW вы как измерили, не поделитесь?

      Ширину канала для сервера, думаю, пока не стоит учитывать - даже при оценке 1Мбит/с = 100 POS'ов, ничто не мешает сделать канал на 20-30 Мбит/с (=2000-3000 POS'ов).

      Комментарий


      • #4
        Сообщение от bwm Посмотреть сообщение
        Сейчас интересует поднятие SSL-сервера именно на универсальном оборудовании (обычный современный стоечный сервер), которое, уже в случае значительного роста SSL-клиентов, будет заменено на какое-нибудь специализированное.

        Вопрос как раз в том, когда наступает этот порог...
        Ответ именно в том, что для линукса важно не только само железо, а то, чтобы весь софт был скомпилирован именно под это железо и именно под эту задачу 8-((

        Сообщение от bwm Посмотреть сообщение
        vyurin, а цифру в 500 сессий на NSG-1000/GW вы как измерили, не поделитесь?
        Я не говорил "измерили", я говорил "оцениваем". Экстраполяцией стенени загрузки сервера при меньшем числе клиентов. Или экстраполяцией числа клиентов при полной загрузке менее мощных железок. Собирать стенд из 501 железки - честно скажу, руки не дошли. И никто из клиентов пока реально на эту цифру не вышел (хотя некоторые движутся к ней довольно бодрым темпом).

        Сообщение от bwm Посмотреть сообщение
        Ширину канала для сервера, думаю, пока не стоит учитывать - даже при оценке 1Мбит/с = 100 POS'ов, ничто не мешает сделать канал на 20-30 Мбит/с (=2000-3000 POS'ов).
        Здесь вы, конечно, потеряли самое важное здесь слово, сколько я его ни почёркивал - _одновременно_ работающих POS-ов. Сколько времени реально занимает приём-передача данных в одной транзакции? 1-2 секунды, даже по самым медленным каналам. А сколько времени нужно, скажем, кассирше в супермаркете, чтобы перелопатить всю тележку, пошаманить с каким-нибудь нечитающимся штрихкодом, дождаться, пока клиент выудит из бумажника кредитку, обнюхать и общупать её со всех сторон, засунуть в POS и правильно прокатать с 3-й попытки, дождаться, пока всё оно выползет из принтера, пока клиент поставит свой автограф, спрячет кредитку в бумажник, бумажник в дальний карман, и наконец откатится со своей телегой? Минут 5, т.е. 300 сек. Т.е. реально POS работает менее чем 1/100 часть времени - даже если считать, что клиенты расплачиваются сплошь кредитками. Так что можете спокойно умножать число POS-ов в системе на 100. 1 Мбит/с достаточно для системы из 10 000 POS-ов, поскольку в каждый момент из них будет работать около 100.

        Ну или подойдём с другой стороны: сколько байт передаётся в ходе одной транзакции? Можно посмотреть трассы - несколько сотен всего-то. Сколько транзакций в час (в самый загруженный час пик) у вас происходит со, скажем, 1000 POS-ов? Вот из этого и можно исходить при расчёте потребной производительности процессора и полосы пропускания.

        По здравому смыслу, умножаем на 2, чтобы иметь запас на случай пиковых всплесков нагрузки. Ну, на 3. Всё равно получается очень немного.
        http://www.nsg.ru

        Комментарий


        • #5
          Сообщение от vyurin Посмотреть сообщение
          Ответ именно в том, что для линукса важно не только само железо, а то, чтобы весь софт был скомпилирован именно под это железо и именно под эту задачу 8-((
          Я не спорю, что заточенный софт и соответствующее ему проверенное железо будет выполнять свои функции лучше, чем коробочная ОС + универсальный сервер. Я просто считаю, что, обеспечив достаточными аппаратными ресурсами обычный linux и проведя небольшой его тюнинг, можно добиться не_хужшей производительности и надежности системы. Да, возможно, останутся некоторые "лишние" службы, но избыток аппаратных ресурсов позволит нам не замечать этого.

          По вашим оценкам интенсивности работы терминалов я с вами не соглашусь. На POS'ах есть такой неприятный момент, как "закрытие дня". Очень часто оно одинаково для многих точек установки терминалов. Это значит, что в минуту Х на сервер постучится львиная доля POS-ов. Так что надо, чтобы и сервер и канал был готов отработать момент такой пиковой нагрузки.

          Комментарий


          • #6
            Сообщение от bwm Посмотреть сообщение
            Я не спорю, что заточенный софт и соответствующее ему проверенное железо будет выполнять свои функции лучше, чем коробочная ОС + универсальный сервер.
            Да тоже, в общем, не спорю, что просто железом помощнее можно решить задачу. Просто оценки в этом случае становятся ещё более неопределёнными...

            Сообщение от bwm Посмотреть сообщение
            На POS'ах есть такой неприятный момент, как "закрытие дня". Очень часто оно одинаково для многих точек установки терминалов. Это значит, что в минуту Х на сервер постучится львиная доля POS-ов. Так что надо, чтобы и сервер и канал был готов отработать момент такой пиковой нагрузки.
            Да, это меняет дело - коэффициент будет уже не 100, а существенно меньше. Значит, надо оценить, что есть "много" точек установки терминалов. Сколько POS-ов, или какая доля от всего установленного парка, в самом тяжелом случае может одновременно начать закрывать рабочий день? Какой объём данных они при этом передают? И сколько секунд/минут может длиться этот всплеск? В нашу пользу играет, однако, то, что наверняка у них часы не синхронизированы и разброс +/-5 минут вполне реален, так что пик естественным образом размазывается.

            Короче, вывод - принципиально задача разрешима, число клиентов в пределах разумного. С точностью до порядка величины. Дальше ни одна оценка на бумаге нам не поможет, надо ставить хоть какую-нибудь реальную железку и мерить.
            http://www.nsg.ru

            Комментарий


            • #7
              * подписался

              Комментарий


              • #8
                bwm

                При старте stunnel пишет максимальное число сессий в лог - это число вычисляется на основе параметров операционки. Обычно для Linux это 500 одновременных соединений. Вам надо оценить сколько у Вас ПОСов и сколько из них одновременно соединяются с сервером. На самом деле даже если не будет хватать - это легко масштабируется - ставится вторая машина с таким же stunnel - получаем еще 500 соединений - ну и т.д.
                Nick_st

                Комментарий


                • #9
                  Сообщение от nick_st Посмотреть сообщение
                  bwm

                  При старте stunnel пишет максимальное число сессий в лог - это число вычисляется на основе параметров операционки. Обычно для Linux это 500 одновременных соединений. Вам надо оценить сколько у Вас ПОСов и сколько из них одновременно соединяются с сервером. На самом деле даже если не будет хватать - это легко масштабируется - ставится вторая машина с таким же stunnel - получаем еще 500 соединений - ну и т.д.
                  Да просто не хочется разводить большое количество серверов только для достижения нужной производительности. Для обеспечения резервирования второй сервер поставить - другое дело. Нормальные сервера сами по себе тоже недешевые...

                  Если судить по логам stunnel, то у меня с теоретическим количеством клиентов все ОК. Другой вопрос, как с этим справится железо. Поэтому и хотелось найти какое-нибудь средство тестирования.

                  Код:
                  2009.12.08 09:46:24 LOG5[7374:3086624464]: 24414 clients allowed

                  Комментарий


                  • #10
                    bwm
                    оттестировать можно, например, тем же openssl, там есть команда
                    openssl s_client -host host> -port port>
                    которая откроет SSL соединение и будет висеть - написать простенький шеловский скрипт, который откроет необходимое число соединений - собственно
                    вот и тестирование...
                    Nick_st

                    Комментарий


                    • #11
                      Тема еще жива? Каким ПО можно дать нагрузку в 2500-3000 соединений с подложенными файлами (ключи и сертификатами)?

                      Комментарий


                      • #12
                        Откуда такие цифры (2500-3000) соединений? Это должно быть где-то 100000 POSов... POS-ы обычно работает в режиме без постоянного соединения...
                        Банкоматы - да...
                        А так в принципе stunnel должен держать, конечно не один, а штук 10, возможно запущенных на разных серверах....
                        Nick_st

                        Комментарий


                        • #13
                          Нужен совет, как побороть лимит в 500 одновременных подключений в Stunnel'e. Вариант с масштабированием Stunnel'я на другие сервера - не подходит. Может где то в конфиге указан этот лиммит? У кого есть опыт нагрузки в 10000 одновременных коннектов?

                          Комментарий


                          • #14
                            3000 POS'ов если начнут ломится на Stunnel, то это и будут 3000 соединений.

                            Комментарий


                            • #15
                              Сообщение от nick_st Посмотреть сообщение
                              Откуда такие цифры (2500-3000) соединений? Это должно быть где-то 100000 POSов... POS-ы обычно работает в режиме без постоянного соединения...
                              Банкоматы - да...
                              А так в принципе stunnel должен держать, конечно не один, а штук 10, возможно запущенных на разных серверах....
                              3000 POS'ов если начнут ломится на Stunnel, то это и будут 3000 соединений.

                              Комментарий


                              • #16
                                По поводу 500 - https://www.stunnel.org/pipermail/st...er/002165.html

                                Одновременно 3000 обычно не ломятся...
                                Nick_st

                                Комментарий


                                • #17
                                  Есть актуальная информация по количество сокетов с тунеля.(4.56)

                                  Комментарий


                                  • #18
                                    На данный вопрос в общем виде уже ответили здесь:
                                    Другими словами: количество одновременных соединений, который может поддерживать stunnel напрямую зависит от максимального допустимого значение количества открытых файловых дескрипторов в операционной системе и не зависит от версии stunnel (на сколько понимаю примерно половина от этого числа). Таким образом для любой версии stunnel, установленной на Linux-подобной операционной системе, выяснить максимально возможное количество сессий для stunnel возможно по формуле ("ulimit -n") / 2.

                                    О том как изменить максимального допустимое значение количества открытых файловых дескрипторов, и как следствие увеличить значение сессий stunnel? можно найти в интернете по ключевому слову ulimit.

                                    Комментарий


                                    • #19
                                      Ох уж это "волшебное" оборудование NSG... как его линукс не компилируй – все равно при отключении сессии управления без сохранения, несохраненная конфигурация продолжает существовать в каком-то лимбе, который ни посмотреть, ни поправить ни сохранить! что самое опасное т.к. после перезагрузки она гарантированно потеряется и у вас есть риск потерять работоспособность частично или полностью

                                      P.S.
                                      Ну а при уже 300 клиентских устройств подключённых к NSG 1000 средняя загрузка процессора уже составляет более 50 %

                                      Комментарий

                                      Пользователи, просматривающие эту тему

                                      Свернуть

                                      Присутствует 1. Участников: 0, гостей: 1.

                                      Обработка...
                                      X