Mengapa situs-situs besar menggunakan banyak server alih-alih satu server dengan spesifikasi yang lebih baik?


42

Saya membaca bahwa Stack Overflow menggunakan 10 atau lebih server untuk melayani situs Stack Overflow. Server yang berbeda memiliki fungsi yang berbeda seperti reverse proxy, server database, atau server HTTP.

Saya telah melihat server tunggal mandiri yang kuat dengan spesifikasi ini:

  • 2 x Xeon E5-2630v2 @ 2.60 GHz, total 12 inti, 24 utas; 30 MB
  • 64 GB ECC Reg. hingga 768 GB DDR3 pada 1600 MHz
  • 4 x 120 GB Intel 520/530 Series (IOPS acak 80k, ~ 550 MB / s)
  • HP iLo4 Advanced dengan port manajemen Ethernet khusus.

Mengapa tidak menggunakan server tunggal dengan spesifikasi lebih tinggi seperti 768 GB RAM, 20 TB + HDD, 4+ x Xeon? Apa manfaat menggunakan banyak server atau kelemahan menggunakan satu server dengan spesifikasi tinggi?


4
SE tidak hanya memiliki 10+ server, mereka memiliki setup duplikat di pusat data lain untuk failover. Dan, server belum ditemukan yang dapat menangani semua lalu lintas Facebook atau Google.
Michael Hampton

8
Apa yang terjadi ketika Anda perlu me-reboot server super itu?
Liath

Redundansi ... :)
William Edwards

1
Parallelism ...
Lightness Races with Monica

1
@Spoke: Anda tidak terbatas pada satu koneksi per port. Yang penting adalah bahwa kombinasi (alamat src, port src, alamat dst, port dst) adalah unik.
David

Jawaban:


58

Satu server yang kuat hanya dapat ditingkatkan sejauh ini. Setelah Anda memiliki server paling kuat yang tersedia, situs Anda tidak dapat tumbuh lebih banyak tanpa membaginya di antara server atau membuatnya lebih efisien.

Ada juga faktor biaya. Satu server yang super kuat mungkin berharga sepuluh kali lipat dari dua server yang setengah kuat. Anda ingin dapat membeli perangkat keras Anda pada titik harga yang termurah dan tidak terkunci pada titik harga yang lebih tinggi karena itu satu-satunya yang akan bekerja.

Waktu kerja dan keandalan juga ikut berperan. Dengan dua atau lebih server, satu dapat gagal atau diambil off-line untuk pemeliharaan dan situs dapat tetap terjaga. Anda tidak dapat melakukannya dengan satu server.

Sebagian besar situs web besar menggunakan penyeimbang beban dan beberapa server. Saya dulu bekerja di TripAdvisor. Mereka menerbitkan artikel yang bagus tentang arsitektur TripAdvisor dan bagaimana mereka membuatnya sangat terukur dengan banyak server.

Hal ini dimungkinkan untuk menjalankan layanan canggih pada server tunggal. Salah satu contoh yang saya tahu adalah Mailinator. Penulis menerbitkan artikel tentang arsitektur Mailinator . Dia berfokus pada membuat kodenya lebih efisien daripada membeli server baru. Ini akhirnya menjadi batasan yang menentukan bagaimana layanannya bekerja. Itu membuat surat hanya beberapa jam sebelum mesin tunggal menghapusnya untuk memberikan ruang bagi lebih banyak.

Memutakhirkan satu server dikenal sebagai penskalaan secara vertikal . Menambahkan lebih banyak server dikenal sebagai penskalaan secara horizontal . Untuk informasi lebih lanjut tentang topik ini, berikut adalah beberapa artikel yang membandingkan keduanya:


9
Jika Anda memiliki beberapa server (lebih dari beberapa), dan beberapa cpu mati, Anda memiliki server lain untuk menjaga semuanya berjalan. Jika Anda memiliki 1 server, dan itu sudah selesai, Anda sudah selesai.
Martijn

2
Poin lain yang orang lupa adalah bahwa tidak selalu hal yang baik untuk menjalankan server pada kapasitas maksimal atau di dekatnya. Kami mengukur server kami di telekomunikasi global (yang akan tetap tanpa nama) pada sekitar setengah kapasitas maksimum sebagai aturan umum (tidak ada logika nyata di balik itu - hanya menonton metrik). Anda mulai mengalami masalah dengan antrian komputer, sub-sistem IO, pengalamatan memori dan pertukaran, dan seterusnya di beberapa titik terlepas dari kapasitas perangkat keras hanya karena keseimbangan antara sub-sistem dapat mengalami konflik tergantung pada OS tentu saja. Ada beberapa sistem yang kuat yang memungkinkan lebih banyak.
closetnoc

@closetnoc Saya pikir cara terbaik untuk menggambarkannya adalah bahwa Anda mencoba untuk menghindari kemacetan. Sistem yang seimbang secara teoritis dapat berjalan pada kapasitas 100% tanpa efek samping yang buruk, tetapi apa pun yang harus ditunggu sistem (waktu CPU, I / O, transfer bus, dll ...) akan menyebabkan masalah kinerja. Dengan menjalankan sistem Anda pada kapasitas setengah maks, Anda telah menemukan tempat yang bagus di mana Anda tidak mengalami hambatan seperti itu.
Thebluefish

@Thebluefish Ya dan tidak. Saya seorang pria sistem lama. Sebagian besar sistem memiliki hambatan dalam OS dan perangkat keras internal yang tidak dapat diperbaiki dengan serangan yang lebih cepat, memori, CPU dll. Selain itu, ada batasan dalam OS. Windows cukup bagus karena didasarkan pada VMS, tetapi masih memiliki batas yang tidak dapat disetel seperti VMS. Linux jelas lebih baik. Beberapa server dirancang dengan sedikit batasan perangkat keras seperti HP yang kami gunakan. Tetapi meskipun demikian, tidak pernah merupakan ide yang baik untuk menjalankan antrian komputasi pada kapasitas 100% karena peningkatan interupsi dan pertukaran CPU.
closetnoc

2
Satu keuntungan lain dari penskalaan secara horizontal: hanya ada begitu banyak listrik, bandwidth, pendingin, dll. Yang bisa Anda arahkan ke satu server. Netflix dapat memiliki sebuah kotak dengan daya pemrosesan dan memori yang tak terbatas, tetapi itu tidak akan berguna tanpa pipa yang cukup gemuk untuk mengeluarkan traffic mereka.
Chris Hayes

32

Dari Laksamana Muda Grace Hopper:

Untuk membangun komputer yang lebih besar: "Pada zaman perintis, mereka menggunakan lembu untuk penarik yang berat, dan ketika seekor lembu tidak dapat menggerakkan kayu, mereka tidak mencoba menumbuhkan sapi yang lebih besar. Kita seharusnya tidak mencoba untuk komputer yang lebih besar, tetapi untuk lebih banyak sistem komputer. "

sumber


1
Saya bertemu Grace Hopper beberapa kali di awal karir saya dan menghabiskan waktu bersamanya. Dia benar-benar sesuatu! Satu kucing keren! Kami semua mencintainya. Dia begitu baik dan murah hati dengan waktu dan rahmatnya (pun intended). Kudos karena mengutipnya! Satu suara untuk jalan kembali. Terima kasih!
closetnoc

5
Meskipun ini adalah kutipan yang relevan, ini tidak menjawab pertanyaan. Pendapat seseorang yang tidak berdasar tidak seharusnya berharga di sini.
TankorSmash

7
@NoahSpurrier Karena tidak benar-benar menjawab bagian dari pertanyaan? Itu hanya satu kutipan yang membuat analogi yang tidak berdasar dan tidak menjelaskan mengapa kita harus mengambil lebih banyak server.
Chris Hayes

2
Saya akan mengatakan bahwa itu adalah jawaban yang berguna, tetapi tidak boleh diterima sebagai jawaban karena tidak merinci alasan spesifik. Namun, hal ini jelas menyatakan alasan lengkungan berlebih untuk prinsip pemisahan beban.
Ian T. Small

1
@ Bobson Saya sama sekali tidak berdebat bahwa dia pemain yang penting, saya hanya mengatakan saya ingin melihat jawaban dengan beberapa konten, bukannya satu atau dua kalimat yang kedengarannya bagus.
TankorSmash

10

Stephen menjelaskan pertimbangan utama yang harus diambil ketika memutuskan arsitektur sistem: tradeoff dalam skala vertikal dan horizontal. Saya akan menambahkan beberapa pertimbangan lain:

  • Pemisahan masalah: Anda menyebutkan beberapa sistem yang sangat berbeda: proksi terbalik, DB, server konten, dll. Dari sudut pandang pemeliharaan dan keamanan jelas menguntungkan untuk menjaga tanggung jawab ini tersebar di berbagai sistem sehingga mereka dapat menjalankan OS yang berbeda (versi) jika perlu, dapat diperbarui secara terpisah dan tidak memengaruhi layanan lain saat dikompromikan.
  • Pengiriman konten: ini adalah tujuan akhir dari server web dan cocok untuk model distribusi. Sistem dapat diduplikasi dan tersebar secara geografis sehingga latensi koneksi jarak jauh diminimalkan. Ini juga memungkinkan redundansi . Situs web besar menggunakan penyeimbang beban (satu set server lagi!) Untuk memungkinkan kegagalan otomatis untuk menjaga layanan setiap saat.

Sebenarnya ada seluruh kelas server yang membawa skala vertikal ke tingkat lain: mainframe. Mereka memiliki berbagai keunggulan (kecepatan, keandalan) dan kerugian (biaya) tetapi secara keseluruhan mereka biasanya digunakan ketika volume data yang luar biasa harus ditangani melalui pemrosesan Input-Output dalam apa yang kita sebut pemrosesan transaksi (pikirkan pembelian kartu kredit, perbankan , data pemilu dan sensus). Bank misalnya melayani situs dari server web skala vertikal, sedangkan back-end akan memproses transaksi melalui mainframe.

Perusahaan yang menarik seperti Paypal dan Visa telah pindah dari mainframe menuju sistem cluster dari ribuan sistem skala horizontal. Dalam dunia digital yang berkembang pesat, bahkan mainframe menghantam langit-langit skala horizontal:

“Dengan semua persyaratan ketersediaan dan kinerja, kami tidak dapat terus memproses pembayaran pada mainframe,

Sumber: Adam Banks, di ComputerWorldUK


8
  • Batas ukuran. Kami suka berpura-pura bahwa satu kotak dengan banyak prosesor, chip memori dan disk seragam. Ini tidak sepenuhnya benar, tetapi itu benar jika jumlah Anda tidak terlalu besar. Ada batasan teknis pada panas, energi, kedekatan dll. Yang berarti akan selalu ada batasan praktis tentang seberapa besar sebuah server.

  • Skalabilitas - ada perbedaan besar antara sistem server tunggal, menggunakan memori bersama untuk IPC dan sistem multi server yang menggunakan jaringan atau clustering. Namun perbedaan antara dua server dan 200 jauh lebih kecil - jika Anda telah membangun sebuah sistem yang berskala, Anda dapat skala itu JAUH lebih besar sebelum ada masalah ... dan jika Anda punya, maka sebenarnya tidak perlu untuk satu server besar di tempat pertama.

  • Ketahanan - Satu server adalah tempat yang mungkin 'admin' oops '. Atau ada masalah fisik yang berarti pelayanan terhadap seluruh bagian timah terganggu. (Kebocoran air data center, seseorang menabrak rak dan menjatuhkannya, hal semacam itu). Beberapa server dapat didistribusikan dalam pusat data, atau lebih baik lagi namun didistribusikan secara geografis. Dan jika Anda sudah mendistribusikan aplikasi, penskalaan pada mesin berukuran sedang hampir selalu lebih murah daripada jumlah CPU / memori / IO yang sama pada sejumlah kecil mesin yang lebih besar.

  • Pembaruan - Jika saya menambal server, ini dapat membuat layanan tidak stabil, memerlukan reboot, atau meminta beberapa downtime. Jika saya memiliki 4 server yang menjalankan hal yang sama, saya dapat mengambil satu dari layanan untuk sementara waktu untuk melakukan ini. Dan tinggalkan layanan jika siklus patching / update salah.


7

Mari kita ambil masalahnya dalam skala kecil. Kantor mungil dengan satu server yang menjalankan email, ActiveDirectory, berbagi file, dan situs web untuk perusahaan.

Peretas memukulnya dan Anda harus reboot karena IIS kacau. Atau Exchange perlu pembaruan dan reboot. Atau Active Directory rusak.

Setiap masalah "satu layanan sedang turun" yang terisolasi ini memengaruhi seluruh server, sehingga segala sesuatu yang dibagikan pada server itu akan berdampak pada mereka karena harus reboot atau apa pun.

Begitu seorang pria IT nyata muncul dan melihat server itu, dia akan merekomendasikan membaginya menjadi server yang terpisah (dan memiliki server pengontrol domain cadangan).

Ini pepatah lama "jangan taruh semua telurmu dalam satu keranjang"

Sekarang filosofi itu diterapkan ke server web. Jika saya hanya memiliki satu server web dan saya menerbitkan aplikasi web saya (MyFaceLink.com baru) dan itu menjadi sangat populer, saya punya masalah baru. Saya tidak dapat menghapus situs untuk melakukan pemeliharaan saat pengguna ada di sana. Dan jika crash atau saya mendapatkan terlalu banyak pengguna, saya disembunyikan. Bahkan server tunggal terbesar di dunia akan kewalahan oleh 1 miliar FB yang datang.

Jadi, load balancing ikut bermain, untuk alasan "telur dalam keranjang" yang sama. Sebarkan situs ke 3 server, dan jika ada yang turun, 2 sisanya menangani kapasitas. Jika saya perlu melakukan patch, saya hanya melakukan satu per satu, dan tidak ada yang memperhatikan.

Paling sederhana, ini bukan tentang harga server-mega atau apakah itu benar-benar dapat menangani beban (meskipun bisa jadi). Ini tentang satu titik kegagalan. Setelah bisnis cukup sibuk, dan terjadi 24x7 alih-alih untuk 5 pengguna yang bekerja 8-5, downtime tidak dapat diterima. Pemadaman terjadwal lebih sulit untuk dijadwalkan. Jadi, Anda menyebarkan beban.


+1 untuk menyebutkan satu titik masalah kegagalan .
David Cary

1

Jika seseorang mencoba membuat satu mesin melakukan dua pekerjaan, beberapa bagian dari mesin harus lebih besar tetapi berjalan pada kecepatan yang sama, beberapa dapat tetap dengan ukuran yang sama tetapi akan perlu berjalan lebih cepat, dan beberapa akan perlu lebih besar dan lebih cepat. Sejauh mana masuk akal untuk menggabungkan peran mesin yang lebih kecil menjadi lebih besar, atau membagi peran mesin yang lebih besar menjadi lebih kecil, sebagian besar tergantung pada jenis penskalaan apa yang akan berlaku untuk bagian mesin yang paling mahal. Jika beban kerja terlalu banyak mesin digabungkan menjadi satu raksasa besar, maka biaya akan didominasi oleh hal-hal yang perlu menjadi lebih besar danlebih cepat untuk menangani peningkatan beban kerja. Bahkan jika biaya hal-hal seperti itu linier sehubungan dengan kecepatan dan ukuran, menggandakan beban kerja akan lebih dari dua kali lipat biaya mesin untuk memprosesnya. Fakta bahwa kecepatan meningkat di luar titik tertentu menghasilkan (banyak) peningkatan biaya yang lebih besar dari linier memperbesar efeknya.

Tidak ada titik pasti di mana kepraktisan memaksa pembagian kerja; tergantung pada jenis pekerjaan yang harus dilakukan, mesin yang menggabungkan beban kerja dua mungkin bertahan dengan memori kurang dari dua kali lipat, atau berjalan dengan kecepatan kurang dari dua kali lipat. Di sisi lain, semakin banyak tugas yang diberikan mesin, semakin besar tingkat kebutuhan memori dan kecepatan mulai skala secara linear dengan beban kerja. Semakin jauh melampaui itu, semakin besar peningkatan biaya relatif untuk setiap penggandaan beban kerja.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.