Вопросы Теги

Nginx, проксирующий к нескольким IP-адресам для предварительного просмотра веб-сайта CMS

Причина, которую Ваши диски Sata выполняют в 1.5Gb/s по сравнению с 3.0Gb/s на Вашем сервере, состоит в том, потому что их была ошибка в основной плате, которая вызвала 30-секундные замораживания под тяжелыми рабочими нагрузками. У меня есть X3650, которому я верю, имеет ту же основную плату как Ваш. Я также выполняю Serveraid 8k.

Они узнали, что расширитель SAS, который образует мост к устройствам Sata, имел ограничение, которое препятствовало тому, чтобы он управлял на скоростях на 3.0 ГБ на SATA II устройствами. Вот фактическая ссылка на статью.

http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5071075&brandind=5000008

Это действительно сосет, потому что я потратил много денег, загружающих сервер несколькими твердотельными дисками X25-E, только чтобы узнать, что они застревают, работая в SATA1, который не только ограничивает производительность, но и наносит вред пропускной способности IO на самом жестком диске.

2
задан 2 June 2012 в 19:37
2 ответа

Для всех, кто может наткнуться на это, решением была следующая конфигурация Nginx: 

# Map preview URLs to shared or dedicated IP addresses
map $host $i {
        default         [IP for Shared VHosts];

        123.ourcms.com  [Dedicated IP Address 1];   # www.example1.com;
        456.ourcms.com  [Dedicated IP Address 2];   # www.example2.com;
        789.ourcms.com  [Dedicated IP Address 3];   # www.example3.com;
}

# Map preview URLS to appropriate hostname
map $host $h {

        123.ourcms.com   www.example1.com;
        456.ourcms.com   www.example2.com;
        789.ourcms.com   www.example3.com;
}

...

# Configuration for "preview" server 
server {
    listen                  [OurCMSIPAddress]:80;
    listen                  [OurCMSIPAddress]:443 ssl;
    error_log               /var/log/nginx/error-ourcms.com.log debug;
    root                    /var/www/ourcms.com;
    server_name             ~^(.*)\.ourcms\.com$;
    ssl_certificate         /etc/nginx/conf.d/ourcms.com.chained.crt;
    ssl_certificate_key     /etc/nginx/conf.d/ourcms.com.key;

    location / {
        proxy_pass http://$i;
        proxy_set_header Host $h;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Уловка, и я думаю, что @MarkStosberg намекал на это, а я не понял, заключалась в том, чтобы найдите имя хоста и IP-адрес просматриваемого веб-сайта. Кроме того, серверные блоки для каждого виртуального хоста должны были содержать listen [SharedIPForVhosts]: 80 , а не только listen *: 80 .

0
ответ дан 3 December 2019 в 15:44

except those that have a dedicated IP address for an installed SSL certificate.

It looks to me like you are listening on only one IP address. You will also need 'listen' directives for the additional IPs for the SSL domains. Unless you have an wildcard SSL certificate, I would think that you would need one server{} definition for each of these hosts.

Here's a related pattern that I use that might be helpful if you are trying to avoid the need to maintain your the configs for your SSL Nginx domains completely by hand:

Part of my Nginx configuration is stored under source control as a template. The "init" script for Nginx has been modified so that every time Nginx is reloaded or restarted, a Perl script is scalled that fills in the template variables depending on the environment (alpha, beta, production, etc). A new plain text file is written out and Nginx includes the "rendered" template as an include file.

This allows for new possibilities for automation and DRY. Perhaps it would help in your situation.

0
ответ дан 3 December 2019 в 15:44

Теги

Похожие вопросы