Очень странным выглядит тут сравнение обращения в техподдержку провайдера и звонок в экстренную службу. Наш опыт говорит, что клиентам нравится. На сам сервис обслуживания технически это не влияет никак, а на лояльность и отношение вполне себе.
Новизны, как вы заметили, нет в этом никакой. Но как элемент клиентского сервиса, такой формат обработки входящего трафика далеко не всем знаком и понятен. Мы считаем, что прямое обращение по имени к звонящему клиенту есть хорошо.
К слову, не только МТС таким хвастается. Ещё банки и даже некоторые государственные учреждения.
Обязательным условием пользования нашими услугами, так как мы подчиняемся отечественному законодательству, является заполнение паспортных данных [эта норма у нас будет действовать ещё месяц-два до релиза нового сайта и новой регистрации]. Часто, если клиент физлицо, имя в анкете и есть имя звонящего.
Но юморины с «мойповелитель» встречаются оооочень редко и отрабатываются в ручном режиме. Пусть это будет исключением)
Однако, на наш взгляд, при таком варианте могут возникнуть потенциальные сложности с настройками персистентности в будущем. Например, в самом простом случае не получится отправлять каждый отдельный IP на один и тот же конечный сервер с приложением. Т.е., в зависимости от работы DNS, запрос может уходить на разные конечные сервера, проходя через разные балансеры. Если при этом конечные сервера ничего друг про друга не знают, могут появиться ошибки с сессиями и т.п.
В предлагаемом нами решении можно включить настройки персистентности на уровне LVS и на уровне Nginx, что в итоге позволит закрепить каждый отдельный IP за конкретным конечным сервером.
Т.е, нам кажется, что наш вариант в этом плане более универсальный.
Немного непонятно из вашего комментария, о чём конкретно вы говорите. Давайте вы уточните и мы продолжим беседовать? А проблемы могут возникнуть и не только из-за VRRP.
Если говорить про наш внутренний DNS, то основное, что нам был нужно — это чтобы DNS продолжал работать, если один их backend серверов упадет или мы сами его выключим. Нам оказалось достаточно возможностей Nginx.
Пока мы не встречали никаких проблем именно с работой протокола VRRP и его реализацией в Keepalived.
Были некоторые нарекания именно к работе Keepalived. Не всегда корректно отрабатывал механизм reload (версия 1.2.2, в wheezy). Приходилось именно перезагружать, со всеми вытекающими.
А с сетевым оборудованием проблем не было. Тот сегмент сети, где обитает VRRP трафик, состоит из обычных коммутаторов (L2). Плюс мы помещаем трафик разных VRRP групп в разные vlan'ы.
Будем признательны, если Вы сможете поделиться с нами опытом касательно возможных проблем.
Мы уже готовим новый сайт. Структуру и наполнение переиначим и будет все читабельно и удобно.
Нельзя не согласиться, что на сайте много лишнего на самых видных местах и нет нужного там, где это действительно нужно.
Может, ещё что будет из замечаний? Свежий взгляд для нас очень важен.
Это ценообразование. Мы часто сталкиваемся с вопросом о том, что и сколько стоит.
Кому нужно готовое решение, тот в панели просто жмёт «Создать VDS». Кто интересуется экономикой, тому всегда можно сходить в маны.
Опция включается из панели.
Для пользования вам необходимо создать виртуальную машину, подключить диск и в разделе управления ВМ и дёрнуть переключить в соответствующем разделе в положение «ВКЛ»
Мы не установили готовое решение, а создали его своими силами. Почему бы и не рассказать об этом?
К слову, не только МТС таким хвастается. Ещё банки и даже некоторые государственные учреждения.
Обязательным условием пользования нашими услугами, так как мы подчиняемся отечественному законодательству, является заполнение паспортных данных [эта норма у нас будет действовать ещё месяц-два до релиза нового сайта и новой регистрации]. Часто, если клиент физлицо, имя в анкете и есть имя звонящего.
Но юморины с «мойповелитель» встречаются оооочень редко и отрабатываются в ручном режиме. Пусть это будет исключением)
Согласны с Вами, тоже рабочий вариант.
Однако, на наш взгляд, при таком варианте могут возникнуть потенциальные сложности с настройками персистентности в будущем. Например, в самом простом случае не получится отправлять каждый отдельный IP на один и тот же конечный сервер с приложением. Т.е., в зависимости от работы DNS, запрос может уходить на разные конечные сервера, проходя через разные балансеры. Если при этом конечные сервера ничего друг про друга не знают, могут появиться ошибки с сессиями и т.п.
В предлагаемом нами решении можно включить настройки персистентности на уровне LVS и на уровне Nginx, что в итоге позволит закрепить каждый отдельный IP за конкретным конечным сервером.
Т.е, нам кажется, что наш вариант в этом плане более универсальный.
Нагрузка там минимальная. В пиковые моменты, когда запускаются всякие "ночные" скрипты по крону, бывает около 150-200 запросов в секунду.
Если говорить про наш внутренний DNS, то основное, что нам был нужно — это чтобы DNS продолжал работать, если один их backend серверов упадет или мы сами его выключим. Нам оказалось достаточно возможностей Nginx.
Были некоторые нарекания именно к работе Keepalived. Не всегда корректно отрабатывал механизм reload (версия 1.2.2, в wheezy). Приходилось именно перезагружать, со всеми вытекающими.
А с сетевым оборудованием проблем не было. Тот сегмент сети, где обитает VRRP трафик, состоит из обычных коммутаторов (L2). Плюс мы помещаем трафик разных VRRP групп в разные vlan'ы.
Будем признательны, если Вы сможете поделиться с нами опытом касательно возможных проблем.
Нельзя не согласиться, что на сайте много лишнего на самых видных местах и нет нужного там, где это действительно нужно.
Может, ещё что будет из замечаний? Свежий взгляд для нас очень важен.
Кому нужно готовое решение, тот в панели просто жмёт «Создать VDS». Кто интересуется экономикой, тому всегда можно сходить в маны.
В последнем случае цена — это стоимость «голой» машины без диска и без IP.
То есть, в вашем случае
Это две разных услуги и стоят они по-разному.
Для пользования вам необходимо создать виртуальную машину, подключить диск и в разделе управления ВМ и дёрнуть переключить в соответствующем разделе в положение «ВКЛ»
Вы какими-то не теми хостерами пользуетесь. Нормальные хостеры предлагают git/svn/mercurial из коробки в составе базового набора ПО.