Penerimaan Pusat Data Independen



Halo semuanya! Nama saya Cyril Shadsky, saya adalah kepala Departemen untuk mengelola pusat data eksternal DataLine.

Artikel ini dikhususkan untuk aspek paling penting dari tes penerimaan, serta kemungkinan masalah dan perangkap yang dapat merusak banyak saraf untuk "penguji" pemula.

Jadi, bayangkan: kontraktor yang puas akan melaporkan kepada kami tentang rencana lima tahun dalam empat tahun bahwa tidak ada masalah dan bahwa fasilitas (pusat data atau ruang terpisah) siap untuk dioperasikan. Tampaknya sekarang saatnya untuk memulai tes, tetapi ... pada kenyataannya, kita sudah terlambat. Tes penerimaan harus direncanakan setidaknya pada tahap desain.

Pertanyaan pertama adalah kepada siapa untuk mempercayakan tes? Tentu saja, pembangun! Bagaimanapun, ini jauh lebih mudah daripada memeriksa setiap node secara mandiri atau menyewa komisi independen. Untuk jaga-jaga, saya mengklarifikasi: ini adalah lelucon. Jika semuanya begitu sederhana, artikel ini tidak akan ditulis.

Kontraktor mana pun akan dengan senang hati memverifikasi apa yang ia buat. Sangat bagus untuk mencari kusen di dalam diri Anda dan menyembunyikannya di tempat lain.

Ingat: bahkan kontraktor terbaik dan paling tepercaya adalah orang yang berminat dan segala sesuatu yang disembunyikannya dapat menjadi masalah di masa depan. Karena itu, selalu lakukan tes penerimaan sendiri, atau hubungi organisasi independen.

Jika Anda berpengalaman dan tes tidak membuat Anda takut, Anda dapat melakukannya sendiri. Saya akan mencoba untuk memberi tahu Anda secara rinci bagaimana tes penerimaan diatur dengan kami dan masalah apa yang kami temui di berbagai tahap.

Di Jalur Data ada Direktorat Konstruksi Modal, yang bergerak dalam pembangunan ruang-ruang baru dan pusat data. Setelah konstruksi, semua ini menjadi tanggung jawab layanan pemeliharaan. Penting baginya bahwa semuanya dibangun dengan kualitas tinggi. Direktur teknis kami Sergey Mishchuk adalah semacam "hakim dunia" antara dua divisi perusahaan ini.

Terlepas dari semua pengalaman kami, setiap kali selama tes kami menemukan berbagai sekolah: serius dan kecil. Ini sangat normal. Anda perlu menangkap mereka selama tes, daripada menunggu sampai mereka berubah menjadi masalah. Berikut ini beberapa contohnya.

Dalam 99% kasus, ada keluhan tentang penyegelan lubang di antara dinding atau kamar. Situasi ini dapat dimengerti: pertama Anda perlu meletakkan SCS, kabel daya, pipa freon dan pipa lainnya, dan penyegelan ditunda hingga saat terakhir. Oleh karena itu, pastikan untuk memastikan bahwa itu selesai sebelum memulai pengujian.

Kami wajib melakukan tumpahan germozone. Semua tempat pusat data terletak di area bertekanan terpisah, "rumah di rumah".


Tampilan atas Hermozone

Jika pusat data Anda memiliki zona penahanan, mereka harus dilepaskan dengan air dari selang dan pastikan tidak ada yang bocor.

Tidak ada jalan keluar dari tempat sampah. Di bawah lantai yang ditinggikan pasti akan menemukan pemotongan kabel, roda penggerak, baut dan file lainnya dilupakan oleh para pekerja. Tidak peduli berapa banyak cek yang saya lakukan, selalu ada komentar.

Jika Anda tidak memaksa pekerja untuk segera membersihkan, semuanya akan tetap berbaring ketika mereka membawa dan memasang peralatan. Menurut Anda apa yang lebih mudah? Hilangkan di tempat atau berkeringat dengan senter di bawah rak yang berfungsi dan membersihkan puing-puing konstruksi?

Dan semua ini hanyalah puncak gunung es, masalah yang diberikan untuk pemahaman umum gambar. Sekarang, kita akan menganalisis setiap tahap tes secara rinci dan mulai dengan "tanda nol," yaitu perencanaan.

Persiapan ujian




Dalam hampir setiap artikel, kita berbicara tentang pentingnya pra-perencanaan, dan hari ini juga, kita tidak akan mengganggu tradisi yang mulia ini. Selain itu, perencanaan harus menjadi langkah pertama Anda (jika bukan "nol") dalam melakukan tes.

Uptime Institute merekomendasikan agar Anda mulai merencanakan dan membuat komisi untuk penerimaan pada tahap desain awal pusat data, dan awal pekerjaan verifikasi sudah pada tahap desain.

Kami mulai dengan penerimaan proyek, tidak ada cara untuk melakukannya tanpanya. Yang terbaik adalah menerima sebelum konstruksi, pada tahap desain. Ingat: selalu lebih mudah untuk memperbaiki apa yang "di atas kertas" daripada objek yang sudah dibangun. Dalam beberapa kasus, "sedikit mengutak-atik" pusat data yang sudah selesai umumnya tidak memungkinkan.

Poin-poin berikut juga harus dimasukkan dalam rencana pengujian Anda:

  • Tes apa yang akan dilakukan?
  • Kapan tes akan dilakukan?
  • Siapa yang akan diuji?
  • Karyawan perusahaan mana yang akan terlibat?
  • Apa alat dan peralatan yang akan dibutuhkan (klem saat ini, vibrometer, pencitra termal, anemometer dan banyak lainnya yang tidak jelas, tetapi hal-hal yang diperlukan)?

Untuk setiap pengujian, kami menyusun daftar sistem yang akan diuji, karena di pusat data yang berbeda setiap unit bertanggung jawab atas peralatannya. Di satu tempat kami hanya akan memeriksa listrik dan pendingin udara. Di lain, sistem lain dapat ditambahkan kepada mereka, misalnya, AUGPT, video surveillance, ACS (seperti yang disepakati dengan personel keamanan).

Kami memberikan perhatian khusus pada bangunan itu sendiri. Biasanya, merek beton dan bagaimana lantai dituangkan bukanlah warisan dan spesialisasi kami, tetapi kami perlu memeriksa lantai, pintu, pasokan air, dan sistem pembuangan kotoran yang diangkat .

Dengan kata lain, sebelum memulai tes, Anda harus mengetahui dengan jelas apa dan di mana kami akan menguji untuk menghindari overlay dan kebingungan.

Catatan penting: ketika Anda memeriksa sistem ini atau itu, orang yang membangunnya, atau orang lain yang bertanggung jawab harus berada di dekat Anda. Berlaku untuk semua tahap.

Secara umum, tes penerimaan mencakup langkah-langkah berikut:

  • Verifikasi Proyek
  • Verifikasi Dokumentasi
  • Tes mandiri
  • Pemeriksaan menyeluruh

Kami akan mempertimbangkan masing-masing secara terpisah.

Verifikasi dokumen




Dalam hal apa pun Anda tidak boleh melewati tahap ini dan bahkan melakukannya secara paralel dengan pengujian yang berdiri sendiri. Bahkan jika waktu hampir habis, Anda harus yakin bahwa setiap peralatan dan setiap sistem sesuai dengan yang dinyatakan dalam proyek. Tanpa memeriksa dokumentasi, Anda tidak akan dapat melakukan tes lebih lanjut secara kualitatif, belum lagi sisi hukum dari masalah ini.

Daftar lengkap dokumen yang akan diperiksa adalah individual dan tergantung pada konfigurasi Anda.

Saya memberikan contoh dokumen yang perlu diperiksa selama tes:

  • dokumentasi eksekutif untuk setiap sistem;
  • paspor untuk peralatan;
  • tindakan start-up teknologi;
  • tindakan pengukuran dan tes;
  • tindakan menguji sistem crimping;
  • laporan laboratorium tentang pengukuran resistensi loop tanah dan komunikasi kabel lainnya;
  • instruksi pemasangan peralatan.

Masih ada dokumentasi operasional. Itu tidak selalu ditunjukkan dalam kontrak konstruksi, dan jika tidak, tanyakan kontraktor untuk perjanjian tambahan. Dokumentasi operasional harus berisi instruksi dan algoritme switching dasar, tetapi kami akan kembali ke ini di bagian pengujian kompleks.

Selain semua hal di atas, sangat diinginkan, saya bahkan akan mengatakan, pastikan untuk mengkompilasi tabel beban. Sayangnya, mereka tidak selalu dibuat, tetapi ini adalah dokumen yang penting dan nyaman.

Mengapa itu dibutuhkan?

Biasanya, redundansi di pusat data diatur oleh dua jalur daya, dan Anda perlu memahami beban apa yang akan mengalir ke satu balok karena pemadaman listrik yang lengkap di sisi lainnya.

Tampaknya skema umum untuk ini sudah cukup. Tetapi akan jauh lebih nyaman bagi spesialis Anda untuk bekerja dengan tabel. Lebih kecil kemungkinannya ketinggalan atau bingung.

Tentu saja, kita tidak dapat mendamaikan setiap tindakan dengan kenyataan, tetapi perlu untuk memastikan bahwa semua tindakan ada.

Cek Offline




Pemeriksaan otonom adalah langkah selanjutnya dalam tes penerimaan pusat data. Di sini perlu untuk memeriksa secara manual setiap peralatan: pengoperasian, pengaturan, operasi pada beban maksimum dan, tentu saja, penandaan - di mana tanpa itu :) Penting bahwa penandaan tersebut cocok dengan desain. Tetapi sama pentingnya bahwa itu bertepatan dengan kenyataan.


Contoh penandaan sirkuit glikol

Misalnya, untuk sistem distribusi daya, kami menerapkan beban uji dan secara fisik menghidupkan / mematikan setiap mesin di switchboard. Dan, dimulai dengan peralatan IT, kita melalui setiap rak secara bergantian, membuat meja dan memastikan bahwa ketika mesin dimatikan, perangkat keras yang sesuai juga dimatikan.

Tentu saja, kadang-kadang di switchboards secara ajaib muncul mesin yang tidak ada dalam proyek. Tidak apa-apa, yang utama adalah bahwa bebannya tidak melebihi norma, dan ini dicatat dalam dokumentasi.


Papan tombol kanan

Untuk peralatan seperti AC, genset diesel, dan UPS, kami melakukan pemeriksaan mandiri sederhana: on / off, mode operasi, pengaturan, dll. Anehnya, penting untuk memeriksa seberapa baik peralatan diperbaiki. Kami memiliki kasing ketika kacang-kacangan penting bisa dibuka dengan hampir satu jari.

Babak pertama sudah berakhir, dan kami memberi installer waktu untuk memperbaiki kekurangannya, setelah itu kami kembali, dan semuanya berjalan di babak kedua.

Mereka mengatakan bahwa di antara mereka sendiri para pekerja menyebut mereka lingkaran neraka yang memuncak - sangat sering pada inspeksi kedua kami menemukan tiang tembok yang tidak kami perhatikan sebelumnya. Dan itu dimulai: "Apa yang tidak Anda katakan saat itu juga?"

Anda dapat memahami orang lain, tetapi bagi kami itu hampir seperti di film "Watch Out for the Car": Anda mengejar ketinggalan, dan saya melarikan diri. Justru sebaliknya: Anda menghilangkan, tetapi saya menemukan.

Di bawah spoiler ada daftar tes otonom paling penting yang kami lakukan.
Pendingin:
  • inspeksi visual peralatan untuk memenuhi persyaratan manual instalasi;
  • verifikasi keandalan pemasangan pipa, isolasi pipa dan sambungannya;
  • memeriksa keandalan pengikatan peralatan listrik di panel listrik (mesin otomatis, starter magnet, blok kontak);
  • memeriksa panel kontrol untuk operabilitas;
  • memeriksa algoritme operasi perangkat lunak perangkat keras: beralih dari bekerja ke cadangan setelah mensimulasikan kecelakaan, memeriksa rotasi berdasarkan waktu (jika ada).

Catu Daya:
  • inspeksi visual peralatan, verifikasi kepatuhan dengan persyaratan manual instalasi;
  • memeriksa kepatuhan sistem dan komponennya dengan diagram garis tunggal;
  • pengukuran suhu tanpa kontak selektif (dengan indikasi tempat pemeriksaan).

DGU:
  • memeriksa panel kontrol;
  • memeriksa operasi yang benar dari indikasi cahaya dan suara;
  • memeriksa masalah selama pengujian start set diesel generator dalam mode otomatis dan manual;
  • memeriksa kinerja genset diesel selama 6 jam pada 30% dari beban desain.

UPS:
  • memeriksa mulai otomatis UPS ketika baterai dikosongkan ke tingkat maksimum yang diizinkan, memeriksa masa pakai baterai (ketika bekerja pada 100% dari beban desain);
  • verifikasi parameter utama UPS selama operasi pada beban 100%;
  • verifikasi output UPS dalam memotong dalam mode otomatis dan manual ketika beroperasi pada 100% dari beban desain.


Ketika semuanya berfungsi sebagaimana mestinya, tes yang berdiri sendiri selesai, dan bagian paling lucu dimulai: tes komprehensif.

Tes komprehensif




Biarkan saya melakukan penyimpangan di sini dan berbicara tentang apa itu pusat data dan apa yang penting untuk fungsinya.

Pertama-tama, pusat data adalah sistem tunggal, organisme yang hampir hidup. Dan “kesehatannya” secara keseluruhan tergantung pada bagaimana semua organnya berinteraksi.

Misalnya, pendingin udara sering memberi tahu kami: "Apa yang tidak kamu sukai? Lihat, itu berhembus dan mendingin! Semuanya sebagaimana mestinya! ”

Spesialis di DGU menggemakan: "Lihat, semuanya dimulai dan bahkan memberi listrik!" Secara umum, setiap peralatan bekerja dengan baik (kami memeriksanya pada tes otonom), tetapi hanya dengan sendirinya. Layak untuk memulai semuanya bersama-sama, dan sistemnya hancur. Untuk mengidentifikasi masalah yang terkait dengan operasi bersama peralatan, pemeriksaan komprehensif digunakan.

Cakupan tes dapat bervariasi tergantung pada tingkat redundansi: semakin banyak sistem yang saling berhubungan, semakin banyak opsi pekerjaan yang Anda perlu periksa dan debug.

Misalnya, jika kita sedang membangun pusat data Tier III, sangat penting bahwa setiap elemen infrastruktur, termasuk rute kabel dan distribusi, dapat ditutup dengan aman untuk penggantian atau perbaikan. Dengan demikian, jumlah tes yang diperlukan meningkat. Kami secara konsisten mematikan / menonaktifkan berbagai peralatan saat pusat data beroperasi di bawah beban. Perubahan dalam satu sistem tidak harus mengarah pada kegagalan di yang berdekatan.

Klarifikasi penting No. 1: semua tes komprehensif dilakukan di bawah beban. Dalam 99% kasus, senapan panas ditempatkan langsung di ruang mesin, dan pusat data "dibakar" - ini adalah bagaimana kami memeriksa kualitas sistem teknik.

Klarifikasi penting No. 2: DGU adalah catu daya pusat data utama. Kota ini adalah sumber alternatif "murah", jadi kami melakukan semua pemeriksaan rumit pada diesel.

Salah satu sistem utama di pusat data apa pun adalah otomasi di papan induk utama dan generator diesel. Sistem ini harus diperiksa dengan sangat hati-hati. Jamb standar - tidak ada transisi ke DGU jika input kota dimatikan. Ini karena beberapa orang memasang DGU, sementara yang lain memasang otomasi, dan peralatan tidak cocok bersama.

Ketika sistem debugged, ada baiknya menyiapkan tabel pengaturan dan meresepkan algoritma ATS. Jika Anda menemukan kontraktor yang sangat baik dan bertanggung jawab (perancang, pembangun) yang secara independen mendokumentasikan semuanya, semakin baik. Kalau tidak, jangan malas dan catat sendiri poin-poin berikut:

  1. setelah berapa detik perintah untuk memulai generator diesel tiba;
  2. setelah berapa detik ada transisi ke DGU;
  3. paragraf 1 dan paragraf 2 dalam urutan terbalik.

Di bawah spoiler, contoh algoritma dari salah satu pemeriksaan yang digunakan oleh kami dan Uptime Institute.
  1. Kami melakukan transisi dari jaringan kota ke grup DGU, mengukur indikator.
  2. Kami kembali.
  3. Matikan sepenuhnya salah satu set generator diesel (matikan komunikasi, mesin otomatis) dan perhatikan bagaimana sistem dimulai tanpa mesin diesel cadangan. Ini dapat menyebabkan masalah yang terkait dengan pengaturan otomatisasi yang salah.
  4. Ketika generator diesel diperiksa, kami terus mengerjakannya dan melakukan tes daya yang tersisa.
  5. Kami mematikan satu UPS dan mengamati bagaimana beban mengalir ke balok lain. Kami menerjemahkan bypass dan sebaliknya, debit baterai.
  6. Kami terus secara konsisten mengikuti skema dan mematikan switchboards.


Kemudian sistem pendingin udara diperiksa. Kami mematikan AC secara bergantian dan, jika mereka memiliki sistem ABP terintegrasi, kami juga memeriksanya.

Jika AC dikonfigurasikan untuk bekerja dalam grup dan secara otomatis beralih dari cadangan ke primer, pastikan untuk memeriksa cara kerjanya.

  • hapus semua koneksi;
  • reboot controller yang bertanggung jawab untuk beralih;
  • matikan sakelar distribusi yang menghubungkan AC;
  • otomatisasi pengujian - terlalu sering sering crash di sini;
  • kami melakukan semua yang dapat ditulis dalam novel "50 Shades of the Data Center".

Untuk sistem glikol, sangat penting untuk memeriksa hidrolika dengan mematikan pompa dan mematikan salah satu penukar panas dan satu atau lebih bagian dari rute.


Di sini Anda dapat melihat bahwa setiap perisai ditandai dan diberikan instruksi singkat

Penting: jika pengalihan dilakukan secara manual, kontraktor harus menyediakan algoritma. Penandaan katup dan kait harus menunjukkan posisi operasi (pembukaan normal, penutupan normal).

Seringkali, kontraktor mengatakan: ini tidak ada dalam rencana pengujian yang disediakan. Anda dapat menjawab ini: paket kecelakaan tidak memberikan :)

Situasi sesekali juga terjadi. Sebagai contoh, selama pengujian UPS, sebuah AC jahat mungkin mengalir untuk mengeluarkan:

"Apa yang kamu lakukan dengan Herodes ?!" Mengapa Anda mematikan pompa?
- Kami tidak mematikan apa pun, kami sedang menguji UPS.
- Dan mengapa kemudian memperkosa pendinginnya? Mereka bisa pecah!
- Itulah sebabnya kami menguji untuk menemukan momen sempit seperti itu.

Tes lain yang sering dilakukan adalah memeriksa sistem pemadam kebakaran. Untuk melakukan ini, kami memutuskan semua otomatisasi dari silinder dan menguji bagaimana arah bekerja. Kebetulan arahnya membingungkan, pembukaan / penutupan tidak berfungsi.

Jangan lupa tentang sistem pemantauan (kami menulis lebih banyak tentangnya di sini dan di sini ). Segera setelah kami mengaktifkan atau menonaktifkan sesuatu, perubahan ini harus muncul di panel. Kami juga memeriksa apakah pemantauan mulai "bodoh" dengan sejumlah besar alarm.

Pastikan untuk menguji kekuatan pemantauan. Dalam hal apa pun Anda tidak boleh kehilangan kendali atas pusat data jika terjadi keadaan darurat.

Kami melakukan segalanya dengan tangan pembangun


Pada awalnya, saya menulis bahwa tes penerimaan harus dilakukan oleh spesialis eksternal. Tetapi ada hal-hal yang harus dibebankan langsung ke kontraktor. Ini adalah demonstrasi peralatan hidup dan mati (serta beberapa pekerjaan lainnya). Pihak penerima pergi dengan daftar periksa dan menuliskan hasilnya. Sesuatu seperti ini:

  • Sisi penerima mengatakan, “Kita harus mematikan pendingin udara No. 34. Kolega, matikan, tunjukkan pada kami bagaimana Anda melakukannya. ”
  • Pembangun menunjukkan dan menjelaskan.
  • Sisi penerima sedang merekam.

Ini adalah aturan bentuk yang baik.


Masalah waktu




Seperti yang sudah Anda pahami, tes penerimaan adalah proses yang panjang. Durasi mereka sangat tergantung pada ukuran pusat data dan jumlah peralatan, jadi di bawah ini saya akan memberikan indikator rata-rata (pusat data untuk 50-100 rak).

  • Memeriksa dokumentasi - 3-5 hari kerja para desainer kuat.
  • Pemeriksaan otonom - 3-5 hari untuk iterasi, karena Anda perlu memeriksa setiap elemen pusat data dan memberi waktu kepada kontraktor untuk memperbaiki kesalahan. , .
  • 2-3 , .

, . , 2-3 . .

, — . , — . . , , .

,




.

. , . , , — . , 10 .

: « , , !». , , . . .

, , , . .

, ? , . , .

, , . — , .

: , , , . « », , IT-, . — , .

- , .

Source: https://habr.com/ru/post/id421547/


All Articles