sgrumi

Рейтинг
8
Регистрация
04.10.2018
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.

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 ----------

Junost:
Это форум, он так работает, в идеале.

То есть вам априори все должны?

Все должны вас просто так любить?

Серьезно?

Нет, это не так работает.

Вот еще одно более-менее простое решение

https://habr.com/post/270187/

Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch

Небольшое вступление

Итак, что же мы получим в итоге?

После прочтения данной стати вы сможете развернуть свое собственное гибкое, расширяемое и к тому же отказоустойчивое облако на базе OpenNebula. Что же значат эти слова? — Давайте разберем:

Расширяемое — это значит, что вам не придется перестраивать ваше облако при расширении. В любой момент вы сможете расширить ваше место в облаке, всего лишь добавив дополнительные жесткие диски в пул ceph. Еще вы можете без проблем сконфигурировать новую ноду и ввести ее в кластер при желании.

Гибкое — девиз OpenNebula так и звучит «Flexible Enterprise Cloud Made Simple». OpenNebula очень простая в освоении и к тому же очень гибкая система. Вам не составит труда разобраться с ней, а так же при необходимости написать для нее свой модуль, т.к. вся система построена так, что бы быть максимально простой и модульной.

Отказоустойчивое — В случае выхода из строя жесткого диска, кластер сам перестроится так, что бы обеспечить необходимое количество реплик ваших данных. В случае выхода из строя одной ноды, вы не потеряете управление, а облако продолжит функционировать до устранения вами проблемы.
AllSerial:
Вы лукавите, если бы всё было хорошо, то серч бы к вам пришел, а не вы в него вернулись.

Сёрч дает клиентов хостерам?

Смешно.

Это ж в основном междухостеровский междусобойчик.

Junost:

ЧСВ разыгралось? )

Ну а как вы думали что является вашей оплатой за бесплатную консультацию? Что является нашей мотивацией?

tmatm:
Обычно, чем дальше, тем ниже становится абонентская плата, т.к. сервер устаревает со временем, и ДЦ снижает цену, но Online.Net решили придумать что-то уникальное и повысить цены почти на 40%.

Они просто начинают избавляться от старого железа и ненавязчиво так выгоняют пользователей с этих серверов.

Junost:

Зато теперь понятно о чем гуглить, разбираться, искать, заказывать.

Да ты просто молодец.

4atka:
Сайт украинской компании.А где родной язык или русский?

Ну как же - вот тут в соседних ветках обсуждают - круче тех.поддержка та, что русского не знает....

;)

Всего: 126