Andris

Andris
Рейтинг
167
Регистрация
10.12.2006

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 часов по стандарту.

Это время можно сократить ценой увеличения продолжительности переноса домена.

myhand, в сравнении с более-менее типичными значениями. Реальная ситуация - Auth NS на VDS, TTL 120, нагруженный проект.

dkmeron, это явно у Вас что-то с почтой или MUA. RU-Center информацию руглишем не рассылает.

Himiko:
Иметь "точку входа". Т.е. сервер, который как раз будет мониторить состояние других серверов и направлять запросы на работающий.

И тогда имеем ровно всё то же самое: одну точку отказа, проблемы с которой сводят на нет наши усилия по размещению двух серверов и т.п.

myhand:
Как минимум - не на несколько суток, а на пару минут. Достаточно сменить IN-A записи в зоне Вашего домена, чтобы они указывали на другой сервер. У нормальных парковщиков доменов - TTL для IN-A записей стоит минут 10-15.

Малые значения TTL могут дать слишком большой overhead.

meijen

1. Могут быть законны. Нужно смотреть, что за ТЗ у них и как и где зарегистрирован;

2. Действует;

3. Всё зависит от ситуации;

4. Правомерны, если речь идёт о Ваших действия по продаже продукции и (или) услуг, совпадающих с классами МКТУ, по которым зарегистрирован их ТЗ.

rutrut, кто регистратор домена?

Dmitry_D_V:
тоже об этом подумал... наверно что то все же чистили...

Объяснением может быть то, что винчестер стоял в корпусе вверх платой, что само по себе нехорошо - и соответственно "коптило" его продувом снизу. Вторым объяснением может быть то, что корпус компьютера был открыт, что тоже нехорошо. И третьим - что винчестер просто лежал на дне корпуса. Это уже без комментариев.

Всего: 1750