cbmvd, посмотрите на услуги от Zenon N.S.P. - там есть как специализированные "почтовые" ТП, так и комбинированные. Из "забугорных" можно воспользоваться FuseMail.
И категорически не советую использовать бесплатные сервисы типа GMail Apps или ПДД от Яндекс для корпоративной почты. Только платные варианты и с предварительным изучением вопроса.
olegisrael: переносим всё в Голлондию. mchost.ru [178.208.73.40]...
Это не Голландия (Нидерланды, к слову), а вполне себе российская AS35415. Тут кто-то ещё писал, что серверы McHost переносятся на Украину. Так вот это не так.
Господа, не ссорьтесь :). Я действительно имел в виду гибибайты применительно к дисковому пространству и специально отметил это, чтобы потом ни у меня, ни у потенциального хостера не возникло вопросов.
Всем, кто отписался в теме по теме :), спасибо. Пока продолжаю изучать рынок.
myhand: Можно и поболее - 120 далеко не 10 минут, о которых писали выше.
Какая роль у этого проекта? WEB-сервер + DNS "сбоку припека"? Что конкретно там может создавать нагрузку? По сравнению с GET/POST HTTP запросами, DNS - это копейки.
Унесите NS на нормальный DNS-хостинг. Раз знаний не хватает - доверьте тому, кто умеет.
120 - это секунды. 120 сек. == 2 мин. И в описанном примере этот Auth NS, обслуживавший около 20 доменов, жил на довольно дохлом VDS. Создавать нагрузку могут как запросы, особенно рекурсивные, так и плохая конфигурация самого сервера имён - вне зависимости от того, что там за демон работает. А что до знаний - так это не мой проект и VDS был.
akaplenko: А вот с этого места можно поподробнее? Основная задача у меня это обеспечение работы сайта 24/7 без перерывов больше 10-15 минут (операторы сидят и делают на сайте заказы, стоит очередь и т.д. :-)). Доступ к сайту - вся россия, снг и европа. У нас как показала практика DNS до большинства пользователей расходится за 1-2 часа, но есть и такие, которые ждут до 12-18 часов. Очень хотелось бы решить эту проблему.?
Эту проблему не всегда можно решить только на Вашей стороне. Процесс ресолва - многоступенчатый процесс и всякие кэши (локальные в браузерах, локальные в ресолверах, у провайдеров) очень много значат для него. Кстати, а что, Вы так часто меняете записи в DNS?
akaplenko: И еще - размещение dns сервера на внешней площадке это очень хорошая штука, но тогда встает вопрос - можно ли как то сделать резервный dns в другом датаценте? Тут как я понимаю не должно же быть трудностей?
И можно и нужно. Есть специальные услуги под названием "DNS-хостинг". Но нужно учитывать географию расположения Ваших secondary и не допускать того, что какие-то из них будут находиться на одном канале за одним маршрутизатором, как это есть к примеру у ресолверов широко и недальновидно используемого OpenDNS.
myhand: Если Вы о изменении NS-записей (домен делегируется на другие ns-сервера) - это занимает до 72 часов по стандарту.
Это время можно сократить ценой увеличения продолжительности переноса домена.
Himiko: Иметь "точку входа". Т.е. сервер, который как раз будет мониторить состояние других серверов и направлять запросы на работающий.
И тогда имеем ровно всё то же самое: одну точку отказа, проблемы с которой сводят на нет наши усилия по размещению двух серверов и т.п.
myhand: Как минимум - не на несколько суток, а на пару минут. Достаточно сменить IN-A записи в зоне Вашего домена, чтобы они указывали на другой сервер. У нормальных парковщиков доменов - TTL для IN-A записей стоит минут 10-15.
Малые значения TTL могут дать слишком большой overhead.
Dmitry_D_V: тоже об этом подумал... наверно что то все же чистили...
Объяснением может быть то, что винчестер стоял в корпусе вверх платой, что само по себе нехорошо - и соответственно "коптило" его продувом снизу. Вторым объяснением может быть то, что корпус компьютера был открыт, что тоже нехорошо. И третьим - что винчестер просто лежал на дне корпуса. Это уже без комментариев.
cbmvd, посмотрите на услуги от Zenon N.S.P. - там есть как специализированные "почтовые" ТП, так и комбинированные. Из "забугорных" можно воспользоваться FuseMail.
И категорически не советую использовать бесплатные сервисы типа GMail Apps или ПДД от Яндекс для корпоративной почты. Только платные варианты и с предварительным изучением вопроса.
переносим всё в Голлондию. mchost.ru [178.208.73.40]...
Это не Голландия (Нидерланды, к слову), а вполне себе российская AS35415. Тут кто-то ещё писал, что серверы McHost переносятся на Украину. Так вот это не так.
Господа, не ссорьтесь :). Я действительно имел в виду гибибайты применительно к дисковому пространству и специально отметил это, чтобы потом ни у меня, ни у потенциального хостера не возникло вопросов.
Всем, кто отписался в теме по теме :), спасибо. Пока продолжаю изучать рынок.
Можно и поболее - 120 далеко не 10 минут, о которых писали выше.
Какая роль у этого проекта? WEB-сервер + DNS "сбоку припека"? Что конкретно там может создавать нагрузку? По сравнению с GET/POST HTTP запросами, DNS - это копейки.
Унесите NS на нормальный DNS-хостинг. Раз знаний не хватает - доверьте тому, кто умеет.
120 - это секунды. 120 сек. == 2 мин. И в описанном примере этот Auth NS, обслуживавший около 20 доменов, жил на довольно дохлом VDS. Создавать нагрузку могут как запросы, особенно рекурсивные, так и плохая конфигурация самого сервера имён - вне зависимости от того, что там за демон работает. А что до знаний - так это не мой проект и VDS был.
А вот с этого места можно поподробнее? Основная задача у меня это обеспечение работы сайта 24/7 без перерывов больше 10-15 минут (операторы сидят и делают на сайте заказы, стоит очередь и т.д. :-)). Доступ к сайту - вся россия, снг и европа. У нас как показала практика DNS до большинства пользователей расходится за 1-2 часа, но есть и такие, которые ждут до 12-18 часов. Очень хотелось бы решить эту проблему.?
Эту проблему не всегда можно решить только на Вашей стороне. Процесс ресолва - многоступенчатый процесс и всякие кэши (локальные в браузерах, локальные в ресолверах, у провайдеров) очень много значат для него. Кстати, а что, Вы так часто меняете записи в DNS?
И еще - размещение dns сервера на внешней площадке это очень хорошая штука, но тогда встает вопрос - можно ли как то сделать резервный dns в другом датаценте? Тут как я понимаю не должно же быть трудностей?
И можно и нужно. Есть специальные услуги под названием "DNS-хостинг". Но нужно учитывать географию расположения Ваших secondary и не допускать того, что какие-то из них будут находиться на одном канале за одним маршрутизатором, как это есть к примеру у ресолверов широко и недальновидно используемого OpenDNS.
Если Вы о изменении NS-записей (домен делегируется на другие ns-сервера) - это занимает до 72 часов по стандарту.
Это время можно сократить ценой увеличения продолжительности переноса домена.
myhand, в сравнении с более-менее типичными значениями. Реальная ситуация - Auth NS на VDS, TTL 120, нагруженный проект.
dkmeron, это явно у Вас что-то с почтой или MUA. RU-Center информацию руглишем не рассылает.
Иметь "точку входа". Т.е. сервер, который как раз будет мониторить состояние других серверов и направлять запросы на работающий.
И тогда имеем ровно всё то же самое: одну точку отказа, проблемы с которой сводят на нет наши усилия по размещению двух серверов и т.п.
Как минимум - не на несколько суток, а на пару минут. Достаточно сменить IN-A записи в зоне Вашего домена, чтобы они указывали на другой сервер. У нормальных парковщиков доменов - TTL для IN-A записей стоит минут 10-15.
Малые значения TTL могут дать слишком большой overhead.
meijen
1. Могут быть законны. Нужно смотреть, что за ТЗ у них и как и где зарегистрирован;
2. Действует;
3. Всё зависит от ситуации;
4. Правомерны, если речь идёт о Ваших действия по продаже продукции и (или) услуг, совпадающих с классами МКТУ, по которым зарегистрирован их ТЗ.
rutrut, кто регистратор домена?
тоже об этом подумал... наверно что то все же чистили...
Объяснением может быть то, что винчестер стоял в корпусе вверх платой, что само по себе нехорошо - и соответственно "коптило" его продувом снизу. Вторым объяснением может быть то, что корпус компьютера был открыт, что тоже нехорошо. И третьим - что винчестер просто лежал на дне корпуса. Это уже без комментариев.