Александр Фролов

Александр Фролов
Рейтинг
155
Регистрация
27.12.2007
Должность
Владелец ИТ-компании Shop2YOU
Интересы
Основатель сервиса Shop2YOU — cоздание интернет-магазинов

Про DVD:

vandamme:
их ща с огнем не сыщешь, е мае, внехние харды для чего придумали? с болванками возиться..

Ну вообще DVD-R(+-) у нас продаются, в технологических упаковках, и очень дешево. Да вот хотя бы в Ашане.

Что касается внешних дисков, то мрут они, бедолаги, прямо в этих коробочках... Опять нужно как минимум на два диска писать. Мы используем DVD для архивного хранения (годы), а оперативные резервные копии (часы, дни, недели, месяцы) держим на жестких дисках серверов (RAID).

А так согласен - DVD не идеал, а компромисс. Запись на них идет довольно долго, да и емкость маловата. И портятся они тоже. Есть, конечно, отличные решения по очень надежному архивному хранению на жестких дисках от EMC, но цена пока для нас великовата...

Если общий объем данных сайта невелик, возьмите в другом датацентре виртуальный сервер и настройте автоматическое скачивание файлов сайта по фтп и хранение бекапов. Периодически закачивайте бекапы на свой локальный компьютер. Время от времени записывайте бекапы на DVD.

Можно поднять дома небольшой сервер для автоматического скачивания бекапов, но он должен работать постоянно. А когда дома никого нет, лучше все отключать. Поэтому я и рекомендую сервер бекапов у провайдера, хотя бы и виртуальный.

Еще вариант - разместить сайт не на виртуальном хостинге, а на виртуальном сервере. Тогда можно будет настроить автоматический бекап данных на внешний FTP-сервер, размещенный в другом датацентре.

Не бывает ничего абсолютно надежного. Единственный способ не потерять данные - делать двойное и тройное резервирование бекапов, а также обязательно проверять резервные копии на возможность восстановления.

Зависит от требований к надежности и отказоустойчивости. Если бюджет позволяет, лучше держать два сервера и настроить репликацию баз данных и файлов. Если с сервером что-либо случится, можно будет быстро перейти на резервный сервер.

Так же, если позволяет бюджет, лучше не арендовать серверы, а покупать свои собственные. Я сталкивался с ситуацией, когда в аренду сдаются дешевые и ненадежные серверы. При этом арендная плата такова, что за год-полтора может быть потрачена сумма, достаточная для покупки собственного хорошего сервера.

Ну а когда сервер свой, можно выбрать надежное и производительное решение. А ежемесячные затраты будут минимальны.

А не проще ли будет вместо всех этих заморочек арендовать стойку или несколько мест для установки серверов в датацентре? Там, опять же, не только резервированное питание, но и кондиционирование, круглосуточная техподдержка, толстые каналы до Интернета. Опять же, никаких проблем с законом...

Не очень понятно, зачем так мучиться и делать датацентр в помещении, которое для этого не предназначено и не приспособлено, и где вообще запрещено размещать подобные вещи.

Кстати, я видел подобный датацентр в подвале жилого дома, там генератор стоял в железном ящике рядом с домом, и вроде никаких проблем не было. Кроме разве лишь той, что он получил массу лицензий, но не получил разрешение на эксплуатацию узла связи в Роскомнадзоре. А еще там был толстый оптоволоконный канал до М9.

Кстати, для "квартирного" датацентра такое разрешение получить будет проблематично.

Большое спасибо, буду пробовать!

Вот тут-то я и не понимаю, не получается разобраться по документации...

Мне ведь надо все запросы для всех сайтов на порту 80 проксировать на другой сервер?

Правильно ли я понимаю, что нужно сделать что-то вроде этого:

http {

include mime.types;

default_type application/octet-stream;

...

server {

listen 80;

server_name *; ???

location / { ???

root html;

index index.html index.htm;

}

Но как задать server_name и loсation, чтобы обозначить сразу все сайты?

Или мне для каждого из сотен сайтов нужно отдельно прописывать блок server?

Сентябрь:
Копируете всё на новый, затем на старом делаете проксирование(через nginx) всех запросов на новый.
Затем спокойно переписываете ДНС, как всё обновится, отключаете старый. Даунтайм нулевой.

Да, интересное решение, спасибо!

А не подскажете, как это настроить? Я не большой спец по nginx...

DenisVS:
Клонировать диск, прописать новые сетевые интерфейсы и ad/da.

Так мы клонируем сервер. Потом мы должны его привезти на площадку к провайдеру, и тут возникнут проблемы. Мы не можем просто установить его и включить, т.к. IP уже занят другим сервером, который работает. Поэтому нам придется остановить работающий сервер, изъять его, поставить новый и включить. Во время замены сервера и загрузки ОС сайты будут недоступны как минимум минут 20, и еще не известно, все ли будет хорошо при загрузке нового сервера. Например, окажется, что еще нужно прописывать новый MAC-адрес на маршрутизаторе провайдера.

Кстати, обычно я еще и обновляю ПО сервера, так что клонирование не всегда подойдет.

Хотелось бы все это сделать без предварительного изъятия старого сервера или даже без его остановки. Т.е. поставили новый сервер, перенесли на него все, потом быстро переключили IP или сделали что-то еще и продолжаем работать. Когда убедились, что новый сервер работает, останавливаем старый. Так можно?

Мы начинали администрирование серверов с того, что взяли в аренду сервер с панелью ISPSystem и с услугой администрирования от провайдера. Это позволило нам сразу создать работоспособную площадку, за которой присматривал системный администратор. Потом мы какое-то время учились администрировать сами, задавали вопросы в саппорт, читали книжки, форумы и так далее. Со временем вопросов становилось все меньше и меньше, и в итоге мы полностью отказались от администрирования силами провайдера.

У панели ISPSystem есть очень большое преимущество - разработчики из России, и они окажут помощь, если что не так. И в администрировании тоже. Платно, но оно того стоит, если дело срочное.

Что же касается глюков, то мы уже пользуемся этой панелью много лет. Глюки были, но они никак не отражались на качестве предоставления наших услуг, и довольно быстро исправлялись. Кроме того, есть возможность работать на стабильных версиях, а не на экспериментальных.

В любом случае для физического сервера нужен администратор на постоянной основе, обладающий необходимым опытом. Который будет каждый день читать почту от серверов, от системы мониторинга, решать текущие проблемы, устанавливать и настраивать нужное ПО и т.д. И этому администратору еще нужно доверять, т.к. в его руках весь Ваш бизнес. Сами Вы будете администрировать серверы, или найдете специалиста, это вопрос другой. Но если Вы нанимаете специалиста, то чтобы его контролировать, Вам тоже будут нужны знания.

BorisVorontsov:
Хоть одну вескую и позитивную причину назовите, чтоб переходить на vps/vds. Если правильно понял, нет даже нормальных средств для автоматического отключения сайтов или введения задержек на исполнение скриптов/подключений (снижая нагрузку), поэтому и требуется ребут. Выходит, что надо брать точно такой же сервак как у обычного шаред хостера и круглосуточного админа в приданное? Н-да, стоимость панели управления на этом фоне меркнет. Пойду копать инфу, что такое облачный хост.

Причина перехода с виртуального хостинга на свой физический сервер фактически одна - проект достиг такого уровня, что требования к ресурсам хостинга не могут быть удовлетворены в рамках виртуального хостинга. Кроме того, исчерпаны все возможности оптимизации ПО проекта в рамках виртуального хостинга.

Т.е. переходить надо потому, что деваться некуда.

Если Вам нужна высокая нагрузочная способность проекта и высокая надежность, одного физического сервера будет мало. Кроме того, без услуг опытного системного администратора тоже не обойтись.

Что же касается затрат, то обычно прибыль от крупных проектов позволяет выделять средства и на серверы, и на администрирование.

Насчет облачного хостинга ничего не скажу, не пробовал. Но мне кажется, что тут тоже есть свои проблемы, и при высоких требованиях к нагрузочной способности и отказоустойчивости цена не будет маленькой.

А стоимость панели управления сервером - да, ее стоимость пренебрежимо мала в общих затратах на сопровождение сложного и нагруженного проекта.

Всего: 343