- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Да ты просто молодец
К чему этот стеб и панибратсво?
Посты набиваете, и ЧСВ разыгралось? )
ЧСВ разыгралось? )
Ну а как вы думали что является вашей оплатой за бесплатную консультацию? Что является нашей мотивацией?
1. Взять три VDS в Хетцнеровском облаке и объединить их в vlan
2. На двух из этих трёх разместить ваш проект и настроить репликацию баз данных и т.п. между ними. Третий vds будет выполнять управляющую и контролирующую роль за этим процессом.
3. Выбрать dns-хостинг (dyn.com, dnsmadeeasy.com и т.п.) где есть поддержка Failover Records и внести туда IP адреса вот тех двух vds на которых проект из п.2. И тогда в случае недоступности одного из них тут же весь трафик будет заворачиваться на второй (если оба доступны то равномерно примерно будет нагрузка распределяться)
А VPS в Хетцнере будут иметь стабильные IOPS и не образуется множество бутылочных горлышек, о которых Вы не предполагали в идеальном мире?
Тут нужно реализовывать задачу под клиента, и если такие требования - то тут явно не VPS, и серверы ни в одном ДЦ, и роли разные у оборудования. Ну и клиент должен озвучить бюджет, сколько денег есть, какая нагрузка предполагается, где находятся посетители, что будут делать на сайте, какое SLA для пользователя должно быть обеспечно, какие ограничения на пользвоателя допустимы, какие latency допустимы.
А потом можно уже предагать какую-то рабочую схему. А не плюнуть в первое попавшееся хетзнеровское говно, и подавать его под уникально хорошим соусом, хотя на самом деле это не так.
Вот еще одно более-менее простое решение
https://habr.com/post/270187/
Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch
Итак, что же мы получим в итоге?
После прочтения данной стати вы сможете развернуть свое собственное гибкое, расширяемое и к тому же отказоустойчивое облако на базе OpenNebula. Что же значат эти слова? — Давайте разберем:
Расширяемое — это значит, что вам не придется перестраивать ваше облако при расширении. В любой момент вы сможете расширить ваше место в облаке, всего лишь добавив дополнительные жесткие диски в пул ceph. Еще вы можете без проблем сконфигурировать новую ноду и ввести ее в кластер при желании.
Гибкое — девиз OpenNebula так и звучит «Flexible Enterprise Cloud Made Simple». OpenNebula очень простая в освоении и к тому же очень гибкая система. Вам не составит труда разобраться с ней, а так же при необходимости написать для нее свой модуль, т.к. вся система построена так, что бы быть максимально простой и модульной.
Отказоустойчивое — В случае выхода из строя жесткого диска, кластер сам перестроится так, что бы обеспечить необходимое количество реплик ваших данных. В случае выхода из строя одной ноды, вы не потеряете управление, а облако продолжит функционировать до устранения вами проблемы.
Простое решение это dns failover ip, с двумя-тремя VPS в разных локациях и рсинком файлов и репликацией бд между ними.
Ну а как вы думали что является вашей оплатой за бесплатную консультацию? Что является нашей мотивацией?
Простое человеческое спасибо и консультация других пользователей в вопросах, которые в сфере моей компетенции. Это форум, он так работает, в идеале.
Неуместен был ваш стеб, я задал вполне сложный и адекватный разделу вопрос, а не спросил чем хостинг от фистинга отличается ))
А для профилактики ЧСВ, всем великим гуру одного инструмента стоит помнить, что в оркестре они не одни. Не говоря о том, что не так давно кому-то приходилось их учить не "ходить под себя", кушать вилкой, завязывать шнурки...
Простое решение это 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 ----------
Это форум, он так работает, в идеале.
То есть вам априори все должны?
Все должны вас просто так любить?
Серьезно?
Нет, это не так работает.
В интернете - все грустно с этим.
Лично Вы пробовали работать с этим?
Насколько это не решает проблему, лично Вам известно?
Мы вот работали с этим, и прекрасно знаем. При правильной настройке максимальный простой сайта составит 2 минуты, ровно, меньший таймаут (по крайней мере в нашей связке, powerdns + unbound) установить было нельзя.
Настроить это и поднять сможет школьник, спрашивали простое и отказоустойчивое решение.
Это решение в соотношении - сложность реализации/отказоустойчивость/скорость работы - лучшее из того что предлагали в данной теме.
Простой в 2 минуты - это лучше чем судорожно восстанавливать сайт из бекапов 30-60 мин. (зависит от опыта).
Что здесь делать? Как определить, что не нужно с ним больше работать?
Тут конечно затык есть, но мониторинг серверов никто не отменял.
Лично Вы пробовали работать с этим?
Насколько это не решает проблему, лично Вам известно?
Проверялось. Конечно, решает.
Причем нередко с огромными задержками. Вплоть до суток.
Когда ваш потенциальный клиент уже забил на ваш сервис.
Мы вот работали с этим, и прекрасно знаем. При правильной настройке максимальный простой сайта составит 2 минуты, ровно, меньший таймаут (по крайней мере в нашей связке, powerdns + unbound) установить было нельзя.
Как проверяли?
Из своего офиса/дома да с площадок мониторинга, где все отлично с качеством роутеров и все как подобает с настройками DNS?
Повторю цитату с фактом, то теперь поменьше текста приведу, чтобы сфокусировать ваше внимание:
Сегодня, кстати и в офисы ваши потенциальные клиенты зачастую ставят подобные "домашние" роутеры.
Настроить это и поднять сможет школьник, спрашивали простое и отказоустойчивое решение.
Это решение в соотношении - сложность реализации/отказоустойчивость/скорость работы - лучшее из того что предлагали в данной теме.
Ключевое слово "школьник".
Из плюсов - это простое в описании решение. Новичок поймет и не испугается.
Из минусов - оно не решает проблему отказоустойчивости, а только делает вид, что решает.
"Если я не могу понять как решить проблему на самом деле, то я буду использовать то, что напоминает решение, и мне все равно, что это не работает на самом-то деле"
Это когнитивное искажение.
Мониторинг серверов никто не отменял.
Как именно вы предлагаете это сделать "просто по бырому", было бы интересно услышать?
Uptimerobot к примеру. Он умеет мониторить и Apache и MySQL, проще чем добавить сервер в него - нет ничего.
Мы же говорим не о проф. отказоустойчивом решении, а о простом отказоустойчивом решении. То что гуру будут делать по другому - это ясно, но для новичка - это подходит, более чем.