Bagaimana cara mengkonfigurasi UPS untuk memulai kembali server dalam urutan yang benar?


12

Di sini kami memiliki beberapa server dan hampir masing-masing memiliki UPS khusus. Ada dependensi di antara mereka sehingga mereka harus diaktifkan dalam urutan yang benar. Pada akhirnya kami mengalami masalah serius dengan catu daya, sehingga server dimatikan dan kemudian dimulai kembali secara acak ketika daya dipulihkan. Ini bukan masalah jika server dimatikan selama pemadaman, penting mereka bekerja dengan benar tanpa campur tangan manusia begitu daya dipulihkan.

UPS kami cukup murah dan satu-satunya parameter konfigurasi yang berguna untuk tujuan saya adalah power the load xx seconds after power is restored. Secara teori menempatkan penundaan yang tepat pada setiap UPS saya dapat memperbaiki urutan restart server tapi saya tidak percaya UPS akan berperilaku seperti yang diharapkan.

Apakah ini cara yang tepat untuk pergi?
Apakah UPS tingkat tinggi memberikan opsi lain untuk memperbaiki urutan restart?
Satu catatan terakhir: UPS saya ada di kisaran 1000 - 2200 VA


1
Ini adalah salah satu hal menyenangkan yang ditawarkan oleh systemd- kemampuan untuk menentukan dependensi yang tepat dalam proses startup. Tunggu hingga layanan X tersedia sebelum mencoba memulai layanan Y.
MSalters

1
@MSalters AFAIK systemd manajemen ketergantungan hanya berfungsi ketika unit ditangani dengan systemdcontoh yang sama dan tidak untuk layanan yang berjalan di server yang sama sekali berbeda ...
HBruijn

1
@HBruijn: Semacam, pemasangan jaringan misalnya bekerja di server. Dengan kata lain, jika server1 me-mount sistem file yang di-host oleh server2, maka layanan serve1 yang bergantung pada mount akan berhenti sampai server2 memulai layanan tersebut. Dan IIRC Anda juga dapat memiliki server menunggu DHCP (jangan tanya saya mengapa server menggunakan DHCP, tetapi disebutkan dalam jawaban)
MSalters

Jawaban:


25

Jawaban standar untuk ini adalah "tidak sama sekali". Perbaiki perangkat lunak untuk menangani restart secara acak. Jika Anda benar-benar membutuhkan BEBERAPA server untuk memulai lebih dulu (contoh: Active Directory) letakkan di USV yang mungkin bertahan lebih lama. Server berbasis atom berdaya rendah cukup baik sebagai pengontrol Direktori Aktif dan akan bertahan sehari dengan USV kecil.

Apakah UPS tingkat tinggi memberikan opsi lain untuk memperbaiki urutan restart?

Tidak. Saya akan mengatakan bahwa umumnya diasumsikan programmer cukup kompeten untuk mengatasi masalah dengan benar.

Apa yang BISA Anda lakukan adalah:

  • Minta server memulai "secara acak". Kecuali DHCP / Active Directory, tidak ada yang benar-benar menuntut pesanan yang tidak dapat diperbaiki.
  • Memiliki server kontrol setelah beberapa waktu (5 menit) memulai layanan pada berbagai mesin dalam urutan yang benar.

Saya akan mengatakan bahwa jenis pengaturan ini jauh lebih umum. Saya akan menyebut perangkat lunak apa pun yang MEMBUTUHKAN server mulai dalam urutan tertentu (di luar infrastruktur murni) sebagai rusak dan tidak layak untuk bisnis.

Sama seperti catatan: setup kita sendiri adalah biaya rendah 20kva USV (biaya rendah karena kita punya satu digunakan) untuk server, dengan 2000VA USV budak untuk mesin yang berfungsi sebagai "root" dari jaringan (dan mesin cadangan). Slaved berarti bahwa USV berada di belakang yang besar - sehingga hanya beralih ke baterai ketika yang besar (yang berlangsung antara setengah jam dan 8 jam tergantung pada seberapa banyak jaringan komputasi kita yang online) akan memasuki terminal shutdown.


2
Saya pikir ini kadang-kadang lebih mudah diucapkan daripada dilakukan (AD, seperti yang Anda katakan, adalah contoh nyata) tetapi saya setuju. Solusi yang benar adalah bekerja untuk menghilangkan dependensi untuk hal-hal seperti mulai memesan server atau layanan. Jika tidak ada yang lain, itu harus dimungkinkan pada aplikasi web, misalnya, untuk menulis kode yang mengatakan "Jika saya tidak dapat terhubung ke back-end saya, 'tidur' dan coba lagi nanti daripada crash mengerikan".
Rob Moir

Masalahnya dengan AD bahkan bukan AD - sebagian besar IPv4 DHCP yang tidak disiapkan untuk komputer yang sedang online sebelum server dhcp. Ipv6 menangani ini;)
TomTom

Itu benar. IPv4 menyebalkan ... dan saya masih membuat orang-orang di sini bertanya mengapa kita perlu repot dengan "sampah IPv6 bermodel baru ini".
Rob Moir

1
"Biasanya diasumsikan programmer cukup kompeten untuk mengatasi masalah ini" - Anda tidak harus melakukan banyak pemrograman! Tidak, dalam semua keseriusan, ada sejumlah besar alasan suatu sistem mungkin perlu diangkat dalam urutan tertentu. Ya, perangkat lunak harus "gagal dengan anggun" dan mencoba kembali koneksi yang rusak, tetapi itu tidak selalu memungkinkan. Dari apa yang saya ingat, beberapa PDU bagus memiliki kemampuan untuk memulai / menghentikan port individual, jadi mungkin sesuatu dapat dilakukan di sana.
SnakeDoc

1
Saya harus mencari "USV" dan menemukan "kendaraan permukaan tak berawak". Saya tahu ini salah, tetapi saya ingin itu benar.
Braiam

14

Unit Distribusi Daya yang Dikelola (alih-alih UPS) sering mendukung penundaan khusus dalam memungkinkan outlet individu setelah daya dilanjutkan.

Biasanya itu adalah untuk mencegah pemutus sirkuit dari tersandung ketika kabinet penuh sistem menyala pada saat yang sama segera setelah daya dipulihkan, tetapi itu juga dapat digunakan untuk mempertahankan urutan boot dari ketergantungan sistem Anda.


Ya benar. Ini adalah fungsionalitas tingkat lanjut dan tidak diasumsikan bahwa USV benar-benar terhubung ke server - tetapi ini menyalakan rak yang kemudian menggunakan PDU untuk menangani detailnya.
TomTom

6

Saya punya masalah persis ini. Satu-satunya perbedaan adalah kami berinvestasi pada unit daya APC yang dipasang di rak yang kokoh (misalnya APC SmartUPS 3000 ). Dengan perangkat lunak penutupan jaringan APC PowerChute (perangkat lunak PowerChute Network Shutdown) , saya dapat mematikan dan membuka server dalam urutan tertentu. Fitur lain yang berguna dari perangkat lunak ini adalah mengatur server untuk dimatikan pada menit terakhir, yaitu menghitung berapa banyak daya baterai unit APC yang tersisa dan mematikan server dengan waktu yang cukup bagi mereka untuk dimatikan dengan benar alih-alih hanya mematikan.

Perangkat lunak ini ... tidak ramah pengguna tetapi tidak sulit jika Anda meluangkan waktu untuk mengetahuinya. Jika Anda tertarik untuk berinvestasi lebih banyak dalam infrastruktur Anda, ini jelas merupakan jalan yang harus ditempuh.


1
Kami juga memiliki Apc Smart Ups, beberapa di antaranya relatif tua dan mungkin baterai lemah. Sulit untuk melakukan beberapa tes pada mereka karena mereka sedang dalam produksi. Selain kami tidak memiliki beban aneh, maksud saya adalah beban yang dapat menahan daya yang tiba-tiba turun tanpa masalah. Yang mengatakan setiap kali saya mensimulasikan pemadaman UPS berperilaku berbeda dari yang diharapkan, itu bisa disebabkan oleh kesalahan konfigurasi tetapi perasaan saya adalah bahwa UPS tersebut tidak terlalu dapat diandalkan.
Filippo

@Filippo tentu saja YMMV tapi saya memiliki campuran SmartUPS 3000 dan 3000XLMs di beberapa situs menggunakan perangkat lunak PowerChute selama 3 tahun dan setelah mencari tahu perangkat lunaknya, tentu ada kurva pembelajaran dan beberapa pengujian diperlukan, sudah cukup solid.
Winski Tech

2

Kedengarannya seperti unit UPS berbiaya rendah dan tidak mampu dikonfigurasikan untuk waktu tunggu output-on tertentu setelah daya dipulihkan (beberapa unit akhir yang lebih tinggi). Untuk mendapatkan fungsionalitas yang sama, Anda harus memilih host tertentu untuk selalu menyala segera (mungkin sistem mana pun yang diizinkan untuk boot kapan saja) dan meninggalkan semua server lain dalam keadaan mati (dikonfigurasi dalam bios untuk kembali berkuasa mati ketika AC diterapkan, dan untuk menghormati paket ajaib Wake On Lan untuk menghidupkan ketika disuruh melakukannya). Kemudian, pada host utama yang melakukan boot, jalankan skrip / utilitas untuk mengatur waktu pengiriman paket ajaib WOL ke setiap host.

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.