Влад Животнев

Ещё б на скриншоте что-нибудь разглядеть можно было бы...

location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
			root /var/www/inky/data/www/somedocroot;
			error_page 404 = @fallback;
		}
....
		location @fallback {
			proxy_pass http://127.0.0.1:81;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;
			proxy_set_header X-Real-IP $remote_addr;
		}

Пример из ispmanager взял, лень руками писать.
Логика такая: здесь описаны 2 location (у вас в nginx описан только один из них). Первый - "отдавать статические файлы, подходящие под регулярно выражение напрямую через nginx". Второй - виртуальный location, в который нельзя попасть через какой-либо url, но который можно использовать в реврайтах и внутри конфигурации. Сам локейшн второй - "спроксировать запрос в апач" ( в данном случае, висящий на порту 81).
Ну а дальше всё просто - строчка:
error_page 404 = @fallback;
Означает "если запрошенного статического файла нет в docroot - передай запрос в виртуальный location @fallback" - так запрос попадёт в апач и ваши скрипты-реврайты сработают.

Мхм. Балансировка на основе DNS очень "медлительная" - у некоторых провайдеров такой адовый кеш на резолверах, что вы сервер успеет с нуля 10 раз настроить, прежде чем люди получат новую запись.

Из реального - 2 DNS сервера на ваших виртуалках, которые отдают А-записи, указывающие на себя с мизерным TTL (вроде одной минуты). На слабеньком сервере настраиваете proxy_pass в nginx, на ошибку 502 вешаете нужную красивую заглушку. Не то, чтобы золотая пуля, но большая часть людей будет ходить всегда на живой сервер.
А статику лучше разместить и там, и там, с аналогичной конфигурацией, если влазит (на отдельном домене, само собой).

Телефонет, имхо. Падают пореже остальных.
М9 - жуткая жуть. Ещё в Химках какой-то ужаснейший был, даже названия не запомнил - съехали оттуда через месяц с кучей аварий.

У вас виртуалка на openvz, скорее всего. Бегите оттуда )
Тем более, скорее всего, действительно плохо настроенная.
Приходите в жаббер, помогу поселиться на digitalocean (там kvm), расскажу как настроить. Первый месяц у do бесплатен.

Киберсквоттеры-с. Смысл мне пока не совсем понятен, но вы просто наткнулись на большую кучку киберсквоттеров, у которых одинаковые настройки на DNS-серверах для всех доменов. Да и конфиг зоны там один, скорее всего.

BTSync, SeaFile, AeroFS

Wordpress с плагином static-html-output
Через сам WP делаете нужный сайт (легко, удобно, всё такое), плагином потом перегоняете его в html-странички.
С видом проблем нет - шаблонов полно, да и делают-переделывают их дешево.

Это всё при условии, что вам не нужно никакой динамики. Если динамика нужна - то просто wp - без плагинов он достаточно шустро работает.

Если просто подзаработать - то PHP (само собой, +css, +html, желательно +js на уровне, необходимом для верстки). Сайтов в мире много, львиная доля - именно на PHP, уж что-то заработать можно будет при должно уровне.
Но выше справедливо отметили, что программистом просто так стать не получится. Кодером - вполне. Вам нужно хорошо представлять, где будут запускаться ваши приложения, что для этого нужно. Да и инструменты, в конец концов, для, собственно, разработки и тестирования настроить - то ещё веселье.

Выводит STDERR в STDOUT, действительно. Нужно это за тем, чтобы, например, делать grep сразу "двух" пайпов.

Если раздел - просто папка - то попросить админов сменить docroot.

Если раздел "создаётся" CMS-иной, то придется городить хитрую конструкцию с nginx примерно такого вида:

server {
...
server_name razdel.sub.site.ru
location / { rewrite (.*) /razdel/$1 last; 
}

location /razdel {
			proxy_pass http://гдетамувасапач;
			proxy_set_header Host sub.site.ru;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;
			proxy_set_header X-Real-IP $remote_addr;
} 

location <регулярка для статики> { root /путь/до/статики;} 
}

Либо аналогичную в апаче, но там она отвратно работать будет.

Снаружи (с точки зрения пользователя, который к ним обращается) - ни в чём.
Slave - это и есть secondary.

С точки зрения администрирования, master - это тот NS-сервер, на котором вносятся изменения для вашей зоны. Его slave-серверы автоматически получают (и "применяют") такие изменения. В целом это позволяет менять dns-записи в одном месте.
Соответственно, разница между услугами:
DNS-master Primary+Secondary = никру предоставит 2 сервера, на одном из которых вы сможете вносить изменения в зоне (видимо, через их вебморду).
Secondary only = никру не позволяет вносить изменения в зоне у себя. Вам необходимо поддерживать свой dns-master, на котором вы будете вносить изменения (а никру будет их забирать у вас).

Вся эта истерия в свете того, что при домен должен быть делегирован на, как минимум, 2 DNS сервера с адресами из разных подсетей класса C (например, 8.8.8.8 и 8.8.4.4 - подошли бы для делегирования, а 8.8.8.8 и 8.8.8.4 - нет). А хостеры обычно дают один ip-адрес серверу (тем более, если это виртуальный сервер). И даже если они дают 2 адреса - то в 99% случаев они в одной подсети. Для таких случаев и нужна услуга slave-only.