Что входит в проверку?
Или на другом, специально выделенном хосте.
Причем не только последний, а как минимум за последние три месяца.
Эля экономии места можно использовать схему:
Месячный Full Backup ( 1 число текущего мес, 1 число прошедшего мес, 1 число 2 мес назад)
Недельный Full Backup ( субботмй бэкап за последние 5 недель )
Ежедневный Incremental Backup
Или жестко ежедневно контролировать.
150 вечнозеленых на процессор и на каждого клиента (админка).
Если лицензия - экспресс ( т.е. без возможностей работать в кластере и использовать несколько адресных книг ).
Это очень дорого?
Столько, сколько Вы сочтете необходимым для нормальной работы.
Все равно изменения вносятся только на один сервер, тот, который Primary. Все остальные сервера - Secondary. Они обновляются автоматически через определенный интервал с Primary.
Если NS сервера стоят на надежных хостах, у каждого из которых готовность более 99.99, то достаточно двух. А если каналы к NS серверам регулярно падают ( например один из NS серверов расположен в домашней сети :) ), то лучше иметь более, чем 2 :)
Если делать так, как Вы предлагаете - до будет недоступен, а если на NS нового хостера сначала завести зону, а уж потом менять информацию у регистратора, то, уверяю Вас, перерыва не будет.
Каким образом? Я думаю, что перед переводом NS Вы, таки, заливаете сайт и убеждаетесь в его работоспособности.
Конечно есть. Надо просто четко спланировать переход на нового хостера и делать каждый следующий шаг после проверки правильности предыдущего :)
DNS - один из самых критичных сервисов интернет. Поэтому лучше всего закладываться на регистратора или делать свое.
Да по такому "ТЗ" работать - одно удовольствие!!!
Что ни слепишь, все будет соответствовать :)
Последующее сравнение - две фотки рядом
Несколько пользователей с ограниченным доступом - делаем пользователя для всего сайта, и пользователя для редактирования новостной ленты.
Сохранить заявку - это просто сохранить HTML страницу на локальном диске.
Вот правда придется делать два механизма - один для заливки информации на сайт, а другой для добавления. Ну это не беда.
Вылить из сайта в базу данных - А кто сказал, что файловая система это не база данных?
Если серьезно:
1. Требования к БД.
2. Требования к нагрузке на сайт.
3. Распишите пожалуйста поподробнее про ограниченный доступ (роли, права, зоны)
4. Требования к дизайну
5. Формат для "заливки" в БД.
6. Требования к "админке"
7. Критерии сравнения.
8.
Это "проч." что означает? Система документооборота (Бэк офис) с возможностью клиенту наблюдать за ходом сделки в реальном времени? Тогда пожалуйста описание документооборота в студию. Иначе "проч." рассматривается как возможность закрыть окно броузера.
9.
посылать запросы куда? в интерпол? в БТИ? что делать с ответами на эти запросы?
что означает "и проч." в этом контексте? Я полагаю, возможность сменить скин сайта.
Или я чей-то не догоняю... Аль совсем состарился :(
На всякий случай, объясняю тем кто что-то упустил в том, что такое DNS и прошу не кидать в меня словами в трехбайтной кодировке.
Объясняю очень примитивно и неполно.
Верхний уровень:
Корневые сервера всея интернет, записи которых указывают на корневые сервера национальных, географических и прочих зон.
Их немного, и они, как правило прописаны в любом DNS сервере.
Национальный уровень ( к примеру зона .ru):
Ряд DNS серверов, записи которых указывают на сервера, описывающие ту или иную зоону.
Второй уровень:
DNS сервера содержащие собственно описания хостов и сервисов домена, а также домены третьего и прочих уровней. Впрочем, на домен третьего уровня может быть росто указатель на каком NS сервере искать информацию об этом домене.
Когда Вы регистрируете домен Вы, в записи регистрации указываете на каких NS будет располагаться описание Вашего домена.
Описание каждого домена второго уровня должно находится на разных ( как минимум двух) NS серверах и в разных сетях клсса С.
Типы записей в описании домена:
SOA - обязательная запись со служебной информацией.
NS - Сервер имен - должны совпадать с серверами имен, описанными в записи у регистратора.
A - адрес хоста - Вот тут вставляется ip адрес для хоста.
Например:
www A 111.222.133.144
CNAME - синоним. Если хост уже имеет имя, то к нему можно обратится по имени:
vasya CNAME www
Есть еще MX запись - это указатель на почтовый сервер.
Теперь, про то, как эта байда работает.
К примеру, абориен из австралии решил посмотреть данный сайт.
Для того, чтобы браузер аборигена нашел его он должен узнать IP адрес этого форума.
Сначала броузер смотрит, есть ли ip адрес хоста в кэше локального компа. Адреса нет.
Тогда комп аборигена обращается к DNS серверу на предмет выяснения ip адреса.
DNS сервер сначала просматривает свои кэши, и если обнаруживает хост, то возвращает его IP адрес. Но в нашем случае в кэшах ни хрена нет :(
Тогда он смотрит корень домена (.ru) и отправляет запрос к корневым серверам интернета дать адрес сервера, который отвечает за зону ru.
Получив адрес сервера, содержащего зону .ru, DNS сервер аборигена запрашивает там адрес DNS сервера, обслуживающего зону searchengines.ru, и естественно его получает. Далее аборигенский DNS сервер обращается к DNS серверу searchengines.ru и, наконец, получает от него ip адрес для forum.searchengines.ru, который радостно отдает компьютеру аборигена, для установки соединения.
Теперь, немного об отличиях A и CNAME.
A пишется для определения основного имени хоста. И, по идее, на каждый A должна быть обратная запись в зоне DNS описывающей сеть класса С, в которой находится хост. Это надо для однозначного определения. Хотя большинство прописывает A без реверса. ( Реверсная зона DNS служит для обратного преобразования IP адреса в имя хоста. По стандартам в реверсной зоне каждому ip соответствует только один хост. Реверсную зону поддерживает провайдер, который владеет данной сетью класса С. )
Во всех остальных случаях нужен CNAME.
Единственное исключение - корневая запись. Т.е. нельзя написать
CNAME aaa.bbb.ru.
a надо писать
A xxx.xxx.xxx.xxx ( адрес aaa.bbb.ru )
Теперь рекомендации:
1. Если Ваш домен нужен только для сайта - лучше всего использовать NS сервера провайдера. При переносе Вашего сайта с хоста на хост смену ip адреса вы не заметите ( у хорошего хостера ).
2. Если Ваш домен имеет почтовый сервис у другого провайдера - лучше всего держать NS у регистратора и указывать явно Web хостера и почтового хостера.
В этом случае, Вам придется самим указывать ip адреса почтовых серверов и Web сервера.
3. Если Вы имеете свой собственный сервер - поднимите свой собственный DNS сервер на нем. Вторичный DNS сервер можете сделать у регистратора, или провайдера, или просто у друга, который тоже имеет выделенный сервер с DNS. Вы, в свою очередь, можете стать секондари DNS сервером для друга.
4. Если домены ддя вас критичный сервис - Вот тогда и делайте пару серверов и пытайтесь стать независимым ни от кого.
Удачи :)
Тут не в месяц/год, а есть инвестиции и постоянные расходы.
Реально - для меня дорого обошлись инвестиции в оптику до офиса ( вторая уже до того была проложена), и оборудование. ( всякие сервера, стойки, бесперебойники, маршрутизаторы, кондиционирование и.т.д. )
Из постоянных расходов:
1. Сисадмин в штате.
2. Амортизация оборудования.
И, самое главное, собственный труд.
Согласен. И у себя я, в результате сделал это.
Но на это ушло 3 года.
Реально свое - это достаточно трудоемкое дело.
1. Надо иметь 2 очень стабильных собственных сервера
2. Надо иметь как минимум 2 сети класса C зарегистрированных RIPE на Вашу фирму.
3. Надо иметь как минимум 2 канала на разных провайдеров.
4. Надо поднять собственную тупиковую автономную систему
Вот тогда Вы никак не зависите ни от провайдера, ни от хостера, ни от регистратора ни от своего датацентра.
Все остальное иллюзия независимости.
А почему нельзя использовать NS сервера регистраторов?
По крайней мере регистратор от хостера никак не зависит, а у R01 и Руцентра есть такая услуга.
И управляйте ими на здоровье.
И вряд ли регистратор, с бухты-барахты, будет менять IP NS серверов.
Не держите все яйца в одной корзинке.
