Memindahkan penghentian SSL ke tepi meningkatkan contoh 502 kesalahan

Kami menggunakan nginx sebagai load balancer / failover untuk sepasang server hulu. Kami mulai 11/1.

Bagan ini menunjukkan gambar. Di mana tidak ada titik, tidak ada 502 pada hari itu:

Dalam beberapa hari pertama, log menunjukkan sejumlah kecil kode respons 502, kemungkinan karena tweaker atau aktivitas lain saat kami menstabilkan konfigurasi nginx kami. Kemudian kami berlari selama 12 hari tanpa 502s (kecuali satu blip 11/13 - lagi mungkin tweak).

Pada 11/20, kami memindahkan terminasi SSL dari server hulu ke tepi. Sejak saat itu kita melihat 502 setiap hari, dan jumlahnya tampaknya terus bertambah (sebagai persentase dari semua permintaan)

Kemarin, untuk pertama kalinya sejak 11/1, kami mulai menerima keluhan klien.

Meskipun persentase rendah (tidak pernah mencapai 1%) dari semua lalu lintas (~ ½ juta permintaan per hari), mereka biasanya berkumpul dan merentang ~ 10-15 detik. Selama waktu ini, banyak pengguna mengalami penurunan fungsi atau kehilangan akses.

nginx.conf

worker_processes  auto;

events {
    worker_connections  1024;
    use epoll;
    multi_accept on;
}

http {
  include             mime.types;
  default_type        application/octet-stream;
  sendfile            on;
  keepalive_timeout   70;
  keepalive_requests  100000;
  tcp_nopush          on;
  tcp_nodelay         on;

  open_file_cache max=1000 inactive=20s;
  open_file_cache_valid 30s;
  open_file_cache_min_uses 5;
  open_file_cache_errors off;

  gzip on;
  gzip_min_length 1000;
  gzip_types application/x-javascript text/css application/javascript text/javascript text/plain text/xml application/json application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/xml font/eot font/opentype font/otf image/svg+xml image/vnd.microsoft.icon;
  gzip_disable "MSIE [1-6]\.";

  log_format main '$time_iso8601\t$status\t$remote_addr\t$upstream_addr\t$upstream_status\t$scheme\t$request\t$request_time\t$upstream_response_time\t$body_bytes_sent';
  access_log   /var/log/nginx/access.log  main;
  error_log   /var/log/nginx/error.log  error;
  # error_log   /var/log/nginx/error_debug.log

  upstream example {
    server 192.168.1.40:80;
    server 192.168.1.41:80;
  }

  server {
    listen              80;
    listen              443 default ssl;
    server_name         example.com;

#    ssl on;
    ssl_certificate         ssl/example.com.crt;
    ssl_certificate_key     ssl/example.com.key;
    ssl_trusted_certificate ssl/example.com.pem;

    location / {
      proxy_read_timeout      180;
      proxy_pass              http://example;
      proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503 http_504;

      proxy_set_header        Host            $host;
      proxy_set_header        X-Real-IP       $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }
}  

Ketika 502 hit, log akses memberikan nilai-nilai ini:

$status: 502
$upstream_addr: 192.168.1.40, example
$upstream_status: 500, 502

atau

$status: 502
$upstream_addr: example
$upstream_status: 502

atau variasi seperti itu.

Log kesalahan mengatakan:

[error] 21293#21293: *2441745 no live upstreams while connecting to upstream

Detail pemasangan:

• Server Ubuntu 16.04.3 LTS
• versi nginx: nginx / 1.12.2
• 2 core CPU @ 3.00GHz
• RAM 8 GB
• 2x10 Gbe NIC
• HDD 500 GB

Pertanyaan saya:

• Bagaimana cara memindahkan sertifikat ke tepi meningkatkan contoh 502 kesalahan dan bagaimana cara memperbaikinya?
• Mengapa kurs meningkat? Beban aktual cukup rata. Apakah ini semacam kebocoran?

Sunting untuk menambahkan:

• menambahkan keepalive (terima kasih @Wen Garret) tidak menghilangkan 502-an. Kami akan memeriksa malam ini jika mungkin berkurang, maka kami dapat menyesuaikan nilai keepalive sesuai
• Sementara itu, kami kembali mengakhiri SSL di server web (passthrough). Sejauh ini, ini telah menghilangkan 502-an.

NGINX menghasilkan kesalahan 502 karena ia tidak dapat membuat koneksi http ketika diperlukan ke upstreams ( proxy_pass http://example;konfigurasi 'Anda).

Tempat pertama untuk memeriksa adalah server hulu Anda. Periksa log kesalahan server dan syslog untuk mencari indikasi mengapa mereka gagal.

Masalahnya menjadi lebih besar ketika Anda mengubah dari proksi koneksi SSL menggunakan load balancing TCP (stream), untuk mengakhiri SSL dan membuat koneksi http ke hulu? Jika demikian, maka salah satu efek dari perubahan ini adalah upstreams dapat menangani koneksi TCP yang lebih sering:

• Saat proksi koneksi SSL menggunakan TCP (stream) load balancing, semua permintaan dalam koneksi dikirim ke hulu dalam koneksi proksi yang sama.
• Saat mengakhiri koneksi dan kemudian membuat permintaan baru ke hulu, NGINX secara default akan membuat koneksi TCP baru untuk setiap permintaan.

Anda dapat mendorong NGINX agar koneksi TCP tetap terbuka dan menggunakannya kembali untuk permintaan di masa mendatang, dengan mengkonfigurasi NGINX untuk menggunakan koneksi keepalive ke upstreams seperti yang dijelaskan. Perubahan ini dapat mengurangi jumlah 502 kesalahan.

Tambahkan berikut ini ke blok lokasi Anda, di samping proxy_passarahan:

    proxy_http_version 1.1;
    proxy_set_header Connection "";

Tambahkan yang berikut ke konfigurasi grup hulu Anda:

    keepalive 20;

Lihat di sini untuk detail lebih lanjut: https://www.nginx.com/blog/load-balancing-with-nginx-plus-part2/#keepalive