adel92: Лично Вы пробовали работать с этим? Насколько это не решает проблему, лично Вам известно?
Проверялось. Конечно, решает.
Причем нередко с огромными задержками. Вплоть до суток.
Когда ваш потенциальный клиент уже забил на ваш сервис.
adel92:
Мы вот работали с этим, и прекрасно знаем. При правильной настройке максимальный простой сайта составит 2 минуты, ровно, меньший таймаут (по крайней мере в нашей связке, powerdns + unbound) установить было нельзя.
Как проверяли?
Из своего офиса/дома да с площадок мониторинга, где все отлично с качеством роутеров и все как подобает с настройками DNS?
Повторю цитату с фактом, то теперь поменьше текста приведу, чтобы сфокусировать ваше внимание:
кстати, оказывается, огромное количество домашних роутеров напрочь игнорирует TTL в DNS-записях и хранят кэш до пропадания питания
Сегодня, кстати и в офисы ваши потенциальные клиенты зачастую ставят подобные "домашние" роутеры.
adel92:
Настроить это и поднять сможет школьник, спрашивали простое и отказоустойчивое решение. Это решение в соотношении - сложность реализации/отказоустойчивость/скорость работы - лучшее из того что предлагали в данной теме.
Ключевое слово "школьник".
Из плюсов - это простое в описании решение. Новичок поймет и не испугается.
Из минусов - оно не решает проблему отказоустойчивости, а только делает вид, что решает.
"Если я не могу понять как решить проблему на самом деле, то я буду использовать то, что напоминает решение, и мне все равно, что это не работает на самом-то деле"
Это когнитивное искажение.
adel92:
Мониторинг серверов никто не отменял.
Как именно вы предлагаете это сделать "просто по бырому", было бы интересно услышать?
Junost: А то что хостеры годами продлевают недешевые закрепленные топики, и выкупают освободившееся место на аукционе, так это потому что они даже конверсию оценить не могут)
Конечно, не могут.
Ну вот, к примеру, озвучьте как лично вы считаете цифры конверсии, плиз.
Я понимаю, что это звучит оскорбительно для владельцев форума и я могу сейчас отхватить люлей от модераторов.
Но подавляющее большинство хостеров действительно неспособны понять откуда приходят реальные клиенты и куда имеет смысл направить свою маркетологическую энергию и бюджет.
Забавно наблюдать хостеровские представители, прям как дети в песочнице, какашками кидают - "а у вас этого нет, а у вас тут косяк; нет у нас все круто".
Вы правда считаете, что потенциальные клиенты прямо-таки залипнут на этот срач и будут выискивать среди хостеров того, кто более красивыми словами смог парировать?
---------- Добавлено 06.10.2018 в 12:10 ----------
Junost: Нет конечно, разве может один из крупнейших профильных ресурсов с огромной для своей ниши постоянной аудиторией и большим целевым трафиком с ПС давать клиентов?
Лесть для владельцев ресурса, что ли?
Постоянная аудитория - да, состоящая их хостеров? Вы серьезно?
Целевая аудитория - это разработчики да заказчики веб сайтов.
На сайтах, где тусят разработчики веб сайтов - об этом проекте мало кто слышал.
На toster.ru и в русскоязычном stackoverflow, походу, я один даю отсылки на Сёрч, когда о хостинге спрашивают.
wdp: очень просто - если соблюдать первое правило поведения в интернетах - не выкладывать личные данные. По прокси-IP хостеры и их коллекторы еще никому морду не набили.
Коллекторы попу свою с дивана не оторвут за эти копейки.
Затраты на хостинг - смешные сотни, реже тысячи рублей.
adel92: Простое решение это dns failover ip, с двумя-тремя VPS в разных локациях и рсинком файлов и репликацией бд между ними.
"Простое решение" и "Простая вещь, похожая на решение, которую только и способен понять" - это разные вещи.
Failover DNS работает хорошо только локально.
В интернете - все грустно с этим.
По природе своей DNS - многоуровневый кэш. Пробить который, чтобы оперативно заменить адрес сервера - нужно время. Более того, многие простые роутеры вообще кэшируют DNS до своей перезагрузки и игнорируют TTL.
Куда пакет попадает с пользовательского ПК? Как правило — на провайдерский DNS-сервер. И в этом случае, если предположить, что этот сервер находится близко к пользователю, то пользователь попадёт на ближайший к нему узел. Но в значимом проценте случаев (даже простая выборка у нас по офису даёт заметный результат) это будет либо вселенское зло — Google DNS, либо Яндекс.DNS, либо ещё какой-либо DNS.
Чем это плохо? Давайте смотреть дальше: когда такой запрос попадёт на ваш уполномоченный DNS, чей будет source IP? Сервера! Никак не клиента! Соответственно, балансирующий DNS будет по факту балансировать не пользователя, а сервер. Учитывая, что пользователь может использовать сервер не в своём регионе, то и выбор узла на основе этой информации будет неоптимальным. А дальше — хуже. Такой гуглоднс закэширует у себя ответ нашего балансирующего сервера, и будет возвращать его всем клиентам, уже без учёта региона (в нём-то не настроены view). Т.е. фиаско. Кстати, сами производители такого оборудования, при личной встрече мне вполне подтвердили наличие этих фундаментальных проблем с DNS-балансировкой.
Сказать по правде, мы этот метод применяли на заре строительства нашего CDN. Ведь опыта с собственными узлами у нас не было. Системные интеграторы сразу пытались продать под такую задачу по много вагонов оборудования за сумму с большим количеством нулей. А решение на основе DNS в принципе понятно, и работоспособно. Из нашего опыта эксплуатации и выплыли все эти отрицательные стороны. К тому же, вывод узла на профилактику чертовски сложен: приходится ждать, пока протухнут кэши на всех устройствах по пути к пользователю (кстати, оказывается, огромное количество домашних роутеров напрочь игнорирует TTL в DNS-записях и хранят кэш до пропадания питания). А уж что будет, если узел вдруг аварийно отключится — так вообще страшно подумать! И ещё одна вещь: очень непросто понять, с которого узла абонент обслуживается, когда у него проблема. Ведь это зависит от нескольких факторов: и в каком регионе он находится, и какой DNS он использует. В общем, очень много неоднозначностей.
Failover DNS можно попробовать применять вместе с указанием нескольких IP-адресов в записях типа A/AAA на DNS.
Современные браузеры, когда видят DNS отдает им
example.com A 1.1.1.1 2.2.2.2 3.3.3.3
будут способны работать с одним из трех серверов, если даже остальные 2 нерабочие.
Правда и тут есть засада - а что если сервер вышел из строя не полностью, не намертво.
То есть по http тебе отдается нечто кривое в связи с выходом из строя базы данных, но сервер http еще функционирует.
Что здесь делать? Как определить, что не нужно с ним больше работать?
Ну да и с простейшим Failover DNS остается ровно та же засада.
---------- Добавлено 06.10.2018 в 11:26 ----------
Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch
Небольшое вступление
Итак, что же мы получим в итоге?
После прочтения данной стати вы сможете развернуть свое собственное гибкое, расширяемое и к тому же отказоустойчивое облако на базе OpenNebula. Что же значат эти слова? — Давайте разберем:
Расширяемое — это значит, что вам не придется перестраивать ваше облако при расширении. В любой момент вы сможете расширить ваше место в облаке, всего лишь добавив дополнительные жесткие диски в пул ceph. Еще вы можете без проблем сконфигурировать новую ноду и ввести ее в кластер при желании.
Гибкое — девиз OpenNebula так и звучит «Flexible Enterprise Cloud Made Simple». OpenNebula очень простая в освоении и к тому же очень гибкая система. Вам не составит труда разобраться с ней, а так же при необходимости написать для нее свой модуль, т.к. вся система построена так, что бы быть максимально простой и модульной.
Отказоустойчивое — В случае выхода из строя жесткого диска, кластер сам перестроится так, что бы обеспечить необходимое количество реплик ваших данных. В случае выхода из строя одной ноды, вы не потеряете управление, а облако продолжит функционировать до устранения вами проблемы.
tmatm: Обычно, чем дальше, тем ниже становится абонентская плата, т.к. сервер устаревает со временем, и ДЦ снижает цену, но Online.Net решили придумать что-то уникальное и повысить цены почти на 40%.
Они просто начинают избавляться от старого железа и ненавязчиво так выгоняют пользователей с этих серверов.
Лично Вы пробовали работать с этим?
Насколько это не решает проблему, лично Вам известно?
Проверялось. Конечно, решает.
Причем нередко с огромными задержками. Вплоть до суток.
Когда ваш потенциальный клиент уже забил на ваш сервис.
Мы вот работали с этим, и прекрасно знаем. При правильной настройке максимальный простой сайта составит 2 минуты, ровно, меньший таймаут (по крайней мере в нашей связке, powerdns + unbound) установить было нельзя.
Как проверяли?
Из своего офиса/дома да с площадок мониторинга, где все отлично с качеством роутеров и все как подобает с настройками DNS?
Повторю цитату с фактом, то теперь поменьше текста приведу, чтобы сфокусировать ваше внимание:
Сегодня, кстати и в офисы ваши потенциальные клиенты зачастую ставят подобные "домашние" роутеры.
Настроить это и поднять сможет школьник, спрашивали простое и отказоустойчивое решение.
Это решение в соотношении - сложность реализации/отказоустойчивость/скорость работы - лучшее из того что предлагали в данной теме.
Ключевое слово "школьник".
Из плюсов - это простое в описании решение. Новичок поймет и не испугается.
Из минусов - оно не решает проблему отказоустойчивости, а только делает вид, что решает.
"Если я не могу понять как решить проблему на самом деле, то я буду использовать то, что напоминает решение, и мне все равно, что это не работает на самом-то деле"
Это когнитивное искажение.
Мониторинг серверов никто не отменял.
Как именно вы предлагаете это сделать "просто по бырому", было бы интересно услышать?
А то что хостеры годами продлевают недешевые закрепленные топики, и выкупают освободившееся место на аукционе, так это потому что они даже конверсию оценить не могут)
Конечно, не могут.
Ну вот, к примеру, озвучьте как лично вы считаете цифры конверсии, плиз.
Я понимаю, что это звучит оскорбительно для владельцев форума и я могу сейчас отхватить люлей от модераторов.
Но подавляющее большинство хостеров действительно неспособны понять откуда приходят реальные клиенты и куда имеет смысл направить свою маркетологическую энергию и бюджет.
Забавно наблюдать хостеровские представители, прям как дети в песочнице, какашками кидают - "а у вас этого нет, а у вас тут косяк; нет у нас все круто".
Вы правда считаете, что потенциальные клиенты прямо-таки залипнут на этот срач и будут выискивать среди хостеров того, кто более красивыми словами смог парировать?
---------- Добавлено 06.10.2018 в 12:10 ----------
Нет конечно, разве может один из крупнейших профильных ресурсов с огромной для своей ниши постоянной аудиторией и большим целевым трафиком с ПС давать клиентов?
Лесть для владельцев ресурса, что ли?
Постоянная аудитория - да, состоящая их хостеров? Вы серьезно?
Целевая аудитория - это разработчики да заказчики веб сайтов.
На сайтах, где тусят разработчики веб сайтов - об этом проекте мало кто слышал.
На toster.ru и в русскоязычном stackoverflow, походу, я один даю отсылки на Сёрч, когда о хостинге спрашивают.
очень просто - если соблюдать первое правило поведения в интернетах - не выкладывать личные данные. По прокси-IP хостеры и их коллекторы еще никому морду не набили.
Коллекторы попу свою с дивана не оторвут за эти копейки.
Затраты на хостинг - смешные сотни, реже тысячи рублей.
А понтов-то понтов - на миллионы.
Простое решение это dns failover ip, с двумя-тремя VPS в разных локациях и рсинком файлов и репликацией бд между ними.
"Простое решение" и "Простая вещь, похожая на решение, которую только и способен понять" - это разные вещи.
Failover DNS работает хорошо только локально.
В интернете - все грустно с этим.
По природе своей DNS - многоуровневый кэш. Пробить который, чтобы оперативно заменить адрес сервера - нужно время. Более того, многие простые роутеры вообще кэшируют DNS до своей перезагрузки и игнорируют TTL.
https://habr.com/company/ivi/blog/237349/
Куда пакет попадает с пользовательского ПК? Как правило — на провайдерский DNS-сервер. И в этом случае, если предположить, что этот сервер находится близко к пользователю, то пользователь попадёт на ближайший к нему узел. Но в значимом проценте случаев (даже простая выборка у нас по офису даёт заметный результат) это будет либо вселенское зло — Google DNS, либо Яндекс.DNS, либо ещё какой-либо DNS.
Чем это плохо? Давайте смотреть дальше: когда такой запрос попадёт на ваш уполномоченный DNS, чей будет source IP? Сервера! Никак не клиента! Соответственно, балансирующий DNS будет по факту балансировать не пользователя, а сервер. Учитывая, что пользователь может использовать сервер не в своём регионе, то и выбор узла на основе этой информации будет неоптимальным. А дальше — хуже. Такой гуглоднс закэширует у себя ответ нашего балансирующего сервера, и будет возвращать его всем клиентам, уже без учёта региона (в нём-то не настроены view). Т.е. фиаско. Кстати, сами производители такого оборудования, при личной встрече мне вполне подтвердили наличие этих фундаментальных проблем с DNS-балансировкой.
Сказать по правде, мы этот метод применяли на заре строительства нашего CDN. Ведь опыта с собственными узлами у нас не было. Системные интеграторы сразу пытались продать под такую задачу по много вагонов оборудования за сумму с большим количеством нулей. А решение на основе DNS в принципе понятно, и работоспособно. Из нашего опыта эксплуатации и выплыли все эти отрицательные стороны. К тому же, вывод узла на профилактику чертовски сложен: приходится ждать, пока протухнут кэши на всех устройствах по пути к пользователю (кстати, оказывается, огромное количество домашних роутеров напрочь игнорирует TTL в DNS-записях и хранят кэш до пропадания питания). А уж что будет, если узел вдруг аварийно отключится — так вообще страшно подумать! И ещё одна вещь: очень непросто понять, с которого узла абонент обслуживается, когда у него проблема. Ведь это зависит от нескольких факторов: и в каком регионе он находится, и какой DNS он использует. В общем, очень много неоднозначностей.
Failover DNS можно попробовать применять вместе с указанием нескольких IP-адресов в записях типа A/AAA на DNS.
Современные браузеры, когда видят DNS отдает им
example.com A 1.1.1.1 2.2.2.2 3.3.3.3
будут способны работать с одним из трех серверов, если даже остальные 2 нерабочие.
Правда и тут есть засада - а что если сервер вышел из строя не полностью, не намертво.
То есть по http тебе отдается нечто кривое в связи с выходом из строя базы данных, но сервер http еще функционирует.
Что здесь делать? Как определить, что не нужно с ним больше работать?
Ну да и с простейшим Failover DNS остается ровно та же засада.
---------- Добавлено 06.10.2018 в 11:26 ----------
Это форум, он так работает, в идеале.
То есть вам априори все должны?
Все должны вас просто так любить?
Серьезно?
Нет, это не так работает.
Вот еще одно более-менее простое решение
https://habr.com/post/270187/
Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch
Итак, что же мы получим в итоге?
После прочтения данной стати вы сможете развернуть свое собственное гибкое, расширяемое и к тому же отказоустойчивое облако на базе OpenNebula. Что же значат эти слова? — Давайте разберем:
Расширяемое — это значит, что вам не придется перестраивать ваше облако при расширении. В любой момент вы сможете расширить ваше место в облаке, всего лишь добавив дополнительные жесткие диски в пул ceph. Еще вы можете без проблем сконфигурировать новую ноду и ввести ее в кластер при желании.
Гибкое — девиз OpenNebula так и звучит «Flexible Enterprise Cloud Made Simple». OpenNebula очень простая в освоении и к тому же очень гибкая система. Вам не составит труда разобраться с ней, а так же при необходимости написать для нее свой модуль, т.к. вся система построена так, что бы быть максимально простой и модульной.
Отказоустойчивое — В случае выхода из строя жесткого диска, кластер сам перестроится так, что бы обеспечить необходимое количество реплик ваших данных. В случае выхода из строя одной ноды, вы не потеряете управление, а облако продолжит функционировать до устранения вами проблемы.
Вы лукавите, если бы всё было хорошо, то серч бы к вам пришел, а не вы в него вернулись.
Сёрч дает клиентов хостерам?
Смешно.
Это ж в основном междухостеровский междусобойчик.
ЧСВ разыгралось? )
Ну а как вы думали что является вашей оплатой за бесплатную консультацию? Что является нашей мотивацией?
Обычно, чем дальше, тем ниже становится абонентская плата, т.к. сервер устаревает со временем, и ДЦ снижает цену, но Online.Net решили придумать что-то уникальное и повысить цены почти на 40%.
Они просто начинают избавляться от старого железа и ненавязчиво так выгоняют пользователей с этих серверов.
Зато теперь понятно о чем гуглить, разбираться, искать, заказывать.
Да ты просто молодец.
Сайт украинской компании.А где родной язык или русский?
Ну как же - вот тут в соседних ветках обсуждают - круче тех.поддержка та, что русского не знает....
;)