- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
tmatm зачем мониторинг? Запасной сервер по крону мониторит скриптом сервер 1, если тот падает то меняет ип в днс. Так же можно поставить мониторинг на 1 что б чекал 2 если не работает то отправлял на мыло письмо.
Проверять с одного сервера (без перепроверки с другого) - опасно. Будет какая-нибудь проблема в сети между сервером 1 и 2, и станет показываться заглушка, хотя у 99% пользователей сайт открывался абсолютно нормально. Поэтому либо использовать 2 собственных сервера в разных ДЦ и странах для мониторинга (если есть такие серверы), либо использовать сторонний мониторинг, который проверяет из нескольких точек мониторинга.
Что касается обновления IP в ДНС, то это зависит лишь от указанного TTL. Если указать 90, то максимум полторы минуты пользователи будут ходить по старому IP.
Спасибо за ценную информацию. Вопрос лишь в том, как обеспечить синхронизацию данных с первого основного на второй сервер? Предположим, что ежедневно в течении дня на сайье публикуется по 10-15 материалов. WordPress
---------- Добавлено 25.06.2017 в 04:15 ----------
Я подумал, может есть какие-то специальные плагины под CMS WordPress, пускай и платные... Никто не слышал?
Вопрос лишь в том, как обеспечить синхронизацию данных с первого основного на второй сервер? Предположим, что ежедневно в течении дня на сайье публикуется по 10-15 материалов.
Настройте репликацию БД, при необходимости ещё и синхронизацию файлов.
Если в ДНС прописать TTL 300 - 5 мин, как это делает клоудфларе то ип изменится быстро, и это делается не ради 5 минутных падений а когда например вы ночью спите а в дц кабель перерубали.
К сожалению, массе проксирующих ДНС (у дебилопровайдеров) пофиг на эти установки.
Может легко неделя принудительно стоять.
Настройте репликацию БД, при необходимости ещё и синхронизацию файлов.
И зарезервируйте еще и их - вдруг упадет по какой то причине. 😂
G-and-Y, а что будет, если упадет (или просто станет недоступен) сам балансировщик?
Балансировщиков в той схеме 2, есть балансировщик с большим весом и меньшим.
---------- Добавлено 30.06.2017 в 09:47 ----------
неужели DNS так быстро перепрописывается по сети, что для пятиминутных падений имеет смысл его переключать?
пока вся цепочка обновится...
Чтоб избежать этой проблемы можно построить DNS кластер, который обеспечит работу сразу с 2-х серверов, часть абонентов будет обслуживаться одним сервером, а часть - другим. В случае недоступности одного из серверов работа будет проходить с другого.
У популярных сайтов в А-записях можно видеть потому сразу 12-15 адресов. Это же, в свою очередь, помогает защититься от атак.
К сожалению, массе проксирующих ДНС (у дебилопровайдеров) пофиг на эти установки.
Может легко неделя принудительно стоять.
Безусловно, такое бывает.
Но у столь глобальной и фаталистичной формулировки этой проблемы очень почтенный возраст.
Раньше подобных "исключений" было на порядки больше. А сейчас ситуация вполне хорошая и продолжает улучшаться:
1. Меньше потребности в экономии ресурсов.
Никто не держится осознанно за нелепые "принудительные" настройки.
2. Снижается распространённость старого некорректного софта и сопутствующего наследства настроек.
Это постоянный процесс везде, но в сфере ДНС популярность DDOS-атак через резолверы в ряде случаев мотивировала и тех, кто очень хотел ничего не менять.
3. Даже в этой консервативной сфере были не очень известные, но очень полезные технологические новшества.
В частности, EDNS-CLIENT-SUBNET (ECS) расширение появилось только 6 лет назад.
И, например, любимые многими Google DNS всего 3 года как дошли до его совсем полноценной поддержки.
А с ECS кеширование идёт с разделением по подсетям.
Поэтому посетители сайтов со средней посещаемостью - вообще очень редко попадают в какой-либо кеш, кроме собственного.
Т.е. новые посетители перенаправляются даже не с TTL, а с нулевой задержкой.
Проблема же с игнорированием TTL - всё же есть. Это не идеал.
Но на практике речь не о "массе", а об очень незначительной части аудитории (преимущественно, региональной).
Не о неделях задержек, а, в большинстве, о минимумах в 5-20 минут TTL у этой незначительной части аудитории.
Более серьёзные проблемы - у совсем исчезающе малого количества.
Да из него большинство роботы (не ПС) и мобильные.
---------- Добавлено 05.07.2017 в 09:55 ----------
У популярных сайтов в А-записях можно видеть потому сразу 12-15 адресов. Это же, в свою очередь, помогает защититься от атак.
Это действительно простой и рабочий метод, если есть технические возможности у самого сайта. Но исключительно для дополнительной "полировки" стандартного ДНС-способа.
На деле и требуется, чтобы нерабочий адрес совсем не откликался, и браузер достаточно долго ждёт (ХХ секунд) перед новой попыткой.
Вопрос лишь в том, как обеспечить синхронизацию данных с первого основного на второй сервер? Предположим, что ежедневно в течении дня на сайье публикуется по 10-15 материалов. WordPress
Первейший вопрос в том, точно ли вам нужно именно это и насколько критичны задержки в синхронизации.
1. Сайт стандартного типа и размера; данные приемлемы с многодневной давностью; и при проблемах достаточен доступ только на чтение?
Делать не нужно вообще ничего.
Вам уже подсказали вариант с AlwaysOnline.
Из основных минусов:
- "снимок" может оказаться недельной давности;
- будет содержать далеко не всё (если сайт больше стандартной визитки);
- рассказывает посетителям о проблемах сайта, когда полезнее промолчать;
- может не сработать при некоторых ошибках (например, при проблемах БД).
Сходный модуль WSR сочетает "архивный снимок" с всегда свежим дополняющим "рабочим кешем" и интегрирован с гибко настраиваемым мониторингом, который принимает решения при подтверждении из 3 разных ДЦ.
2. Нужен работающий функционал и\или повышенная, но всё же не очень критичная актуальность данных уровня 6-24ч?
Берёте уже описанные здесь методы по самостоятельному построению ДНС-отказоустойчивости и мониторинга.
Добавляете простой, неэффективный, но более чем достаточный баш-скрипт:
- rsync для файлов, не забыв исключить кеши WP;
- бэкап+рестор для БД.
Можно аккуратнее, но это сложнее, а при таких объёмах полная обработка БД не проблема. С удалённым доступом к БД всё реализуется со стороны одного из серверов и правда очень лаконично. Ну разве что, кроме контроля успешности.
Либо с несколько более интересной надёжностью и трудоёмкостью:
- Настраиваете ресторы по расписанию в бэкап-модуле WSR.
- А в CDN указываете резервный сервер, и, вместо использования "снимка", запросы будут перекидываться на него.
А если и он умрёт, то тогда уже "снимок".
3. Актуальность критична на уровне секунд\минут?
Тут уж точно репликация БД, что достаточно просто для такого случая.
Для файлов аналогичным уровнем была бы, например, GlusterFS.
Но в отличие от БД столь частые и действительно нужные изменения на уровне файлов бывают редко у большинства проектов.
И, скорее всего, реальным требованием будет вполне соответствовать куда более простое решение - тот же rsync, только с небольшими поправками в характере применения.
- Сравнительно редкая общая синхронизация.
- Очень частый или событийный запуск для папок с часто меняющимися файлами (вероятно, только картинки).
А в остальном тоже самое.
Запасной сервер по крону мониторит скриптом сервер 1, если тот падает то меняет ип в днс.
Именно в таком виде - мало. Могут быть временные проблемы с доступностью запасного сервера (например, канала) - и в этот момент он будет пытаться переключить основной сервер на себя.
У меня резервный сервер проверяет каждую секунду основные, при N неудачных проверках - делает проверку через промежуточные хостинги (3 хостинга) - если минимум 2 из них ответили и "сказали", что основной сервер недоступен - идет переключение на запасной.
Подскажите NS хостинг с минимальным TTL и возможностью через API редактировать A запись.
В данный момент я остановился на cloudflare TTL 120, есть API и готовые библиотеки на php. Решение для себя вижу такое. Брать два хостинга в разных ДЦ, условно 1-сервер(хостинг) основной, 2-сервер резервный(можно тариф по дешевле) мониторинг по крону на 1-сервере по четным минутам на 2-сервере по нечетным. Если сайт не доступен, то через API смотрим на каком он сервере в данный момент висит и перекидываем на другой. Соответственно если не доступен 1-сервер, то 2-сервер это увидит и переключит на себя, и наоборот. Кроме того на основном сервере по крону раз в N часов проверяем на каком сервере работает сайт и если не на основном, то возвращаем его на основной сервер (последний пункт не актуален если нет разделения на основной и резервный сервер).
Я в свое время делал так:
Покупал 2-3 виртуалки в разных дц, днс вешал тут https://www.cloudns.net/
у них есть смена записи по PHP скрипту или wget-ом, так вот между этими серверами настраивал репликацию, а крон отстукивал скрипт и в случае чего менял А запись, все происходило автоматом, время недоступности измерялось в нескольких минутах