Pengantar
Saya bekerja di sebuah syarikat di mana kita menjalankan banyak kerja batch processing berjuta-juta nota data setiap hari dan saya sudah berfikir baru-baru ini tentang semua mesin yang duduk-duduk masing-masing dan setiap hari melakukan apa-apa selama beberapa jam. Bukankah lebih baik jika kita boleh menggunakan mesin-mesin untuk meningkatkan kekuatan pemprosesan sistem kita? Dalam Seri artikel ini saya akan melihat potensi manfaat menggaji pejabat grid menggunakan persekitaran virtualised.
Dalam Bahagian 1 saya memberi gambaran dari sistem dan teknologi saya akan menggunakan juga dibahas beberapa kemungkinan alasan mengapa anda ingin membuat grid pejabat.
Job Control
Jika anda akan menjalankan kerja maka anda akan memerlukan beberapa cara untuk menetapkan mereka. sistem kawalan pekerjaan yang anda (di server pekerjaan anda) harus benar-benar difikirkan dengan baik bahkan sebelum cuba untuk menjalankan sebuah rangkaian pejabat. Jadi pertama, apa tugas untuk sistem kawalan pekerjaan:
- Berkongsi pekerjaan atas permintaan dari pekerja
- Beritahu pekerja apa jenis pekerjaan untuk menjalankan
- Track pekerjaan
- Pastikan bahawa pekerjaan hanya berjalan sekali
- Menyediakan data pekerjaan untuk para pekerja, atau sekurang-kurangnya memberitahu mereka di mana mendapatkannya
Sistem ini juga perlu diperluas, penyelesaian yang bekerja untuk saat ini dalam satu kes boleh diperbaharui untuk menjalankan beberapa jenis pekerjaan sebagai perniagaan melihat berharga dalam larutan grid. Contohnya, pekerjaan boleh mendapatkan keutamaan, lebih daripada satu jenis pekerjaan mungkin ada (iaitu kod pangkalan beberapa), akhirnya anda bahkan dapat menjalankan mesin beberapa pekerja yang berbeza yang dioptimalkan untuk setiap jenis pekerjaan (walaupun yang bergerak menjauh dari 'pekerja generik 'idea). Selalu cuba untuk berfikir tentang masa depan ketika sistem berkembang, visi jangka pendek boleh menyebabkan kekecewaan jangka panjang dan masa pembangunan meningkat.
Ayub Server
Kita akan memerlukan tempat untuk mengendalikan kerja kita dari, ini harus menjadi sistem hanya dalam grid anda yang mengandungi resource locator tetap, adalah bahawa alamat IP, nama host, URL (menggunakan DNS dalaman), dll Ini adalah kerana pekerja perlu tahu di mana untuk mencari pekerjaan, pekerja perlu mencari sistem kerja kawalan (bukan sistem kawalan pekerjaan mencari pekerja).
Server pekerjaan itu sendiri tidak benar-benar memiliki tugas yang rumit (dalam bagaimanapun sistem asas), perlu untuk menyimpan senarai pekerjaan, pekerjaan tangan keluar, menerima keputusan, dan kemudian menyimpannya untuk turun nanti. Bagaimana bahagian-bahagian ('tangan dari pekerjaan' seperti) yang ditetapkan boleh sangat asas. Kemudian kita dapat memperluaskan sistem untuk menyertakan sebuah antara muka pentadbiran untuk menambah, mengedit, memadam, menunda pekerjaan tapi ini di luar latihan ini.
Tidak ada alasan apapun maka pekerjaan bahawa pelayan anda tidak boleh menjadi mesin virtual yang berjalan dalam pelayan pemprosesan utama anda asalkan tidak terlalu banyak menguras sumber daya dari itu. Server pekerjaan tetapi tidak mengetahui sama ada keperluan yang tinggi, jika turun pada Jumaat malam anda akan kehilangan semua akhir pekan pemprosesan, berpotensi bayaran anda beberapa minggu bernilai masa proses (jika dibandingkan dengan pelayan utama pemprosesan anda sendiri) . Anda mungkin ingin mempertimbangkan untuk menempatkan pelayan pekerjaan anda di persekitaran yang seimbang beban untuk ketersediaan tinggi.
Basic Setup
Tatarajah asas untuk pelayan pekerjaan kami akan terdiri dari apa yang saya menelefon salah satu daripada Limp server saya (iaitu Li Nux, ySql m, L HP). Kod berjalan pada pekerja Thea benar-benar akan bekerja apa kerja boleh berjalan dengan berinteraksi dengan dengan database pekerjaan sistem kawalan. Kemudian kita boleh membuat web service dan benar-benar tangan keluar pekerjaan daripada memiliki pekerja melakukan kerja keras sendiri, tetapi untuk sekarang kita akan terus menggunakan prinsip KISS (Keep it Simple, Stupid!).
Jadi, mari membuat tiga mySQL jadual untuk menangani pekerjaan. Ini akan menjadi `pekerjaan`, `jobRecords`, dan `jobResults`.
Disini Saya menggunakan SQL Buddy alternatif yang sedikit besar untuk phpMyAdmin hanya kerana lebih mudah untuk dipasang pada CentOS (untuk orang lain lihat: 10 alternatif Besar ke phpMyAdmin )
Jadual ini terdiri daripada 5 bidang yang sederhana,
- id: Uniknya mengenalpasti pekerjaan
- Nama: Boleh jadi rujukan pelanggan, atau jumlah pengenal lain
- Status: anda perlu tahu di mana pekerjaan itu pada, misalnya
- 0: Belum bermula
- 1: Dijemput
- 2: Selesai
- started_by: Siapa yang mula melakukan kerja? Hal ini tidak sepenuhnya diperlukan tetapi adalah baik untuk memiliki. Saya cadangkan pelacakan pekerja dengan alamat IP pada rangkaian anda
- started_at: Bila pekerja memulakan kerja? Dengan pengesanan pekerjaan yang belum selesai dalam waktu X jumlah masa kita tahu kita perlu mengambil pekerjaan sekali lagi dan mula memproses oleh pekerja-pekerja lain. Pekerja boleh menghentikan pemprosesan / offline untuk sejumlah alasan, listrik mati, kemalangan, kehilangan rangkaian, dll
Sangat mudah bagaimana jadual ini boleh diperbaharui dengan beberapa medan tambahan untuk membolehkan anda statistik pelacakan, medan waktu selesai untuk melihat berapa lama pekerjaan itu mengambil, sebuah counter untuk melihat berapa ramai pekerja mengambil pekerjaan itu (jelas ini perlu cenderung 1), keutamaan kerja, senarai boleh terus dan terus. Dalam senario pekerjaan yang lebih kompleks akan mungkin untuk menentukan berapa banyak memori pekerja akan memerlukan akses kepada (dan kerana itu hanya menggunakan pekerja sesuai), atau bahkan jenis pekerja akan diperlukan.
Mari menambah pekerjaan beberapa contoh:
Jadual berikutnya lagi adalah cukup sederhana untuk memahami, ini adalah catatan pekerjaan kita. Mereka berkaitan dengan jadual kerja utama dengan sebuah medan `jobs_id`. Yang membuat jadual ini sangat bergantung pada data yang anda perlukan untuk membekalkan para pekerja anda, membolehkan membuat contoh yang sangat sederhana di mana kita mempunyai empat medan:
- id: ID dari nota
- Nama: Nama Orang
- Alamat: alamat Person
- jobs_id: MY pekerjaan yang catatan ini berkaitan dengan
Jadual ketiga dan terakhir terdiri daripada jadual keputusan, itu telah sama make up sebagaimana jadual catatan kami, dan dengan penambahan beberapa medan boleh menjadi sebahagian daripada jadual nota:
- job_record_id: Link hasilnya ke meja kerja
- Keputusan: Data keputusan
... Dan itu semua anda perlukan untuk kawalan kerja! (Walaupun pada tahap yang sangat asas) Dalam kes saya, saya menunjuk ke meja tempat data saya untuk memproses berada, tapi ini bisa saja menjadi jumlah gambar, parameter untuk menjalankan kod simulasi, apa saja.
Memilih pekerjaan
Sebagaimana dinyatakan sebelum ini, para pekerja akan melakukan pengurusan tugas kita untuk kita untuk saat ini, sehingga semua kita harus benar-benar lakukan adalah mencari pekerjaan yang memerlukan pemprosesan dan mendapatkan maklumat. Bagaimana kita melakukan ini? Nah tugas kami memilih kriteria seleksi dan mencari pekerjaan, di SQL saya melakukan hal berikut:
- Mengambil pekerjaan yang tidak ditandakan sebagai lengkap tapi dari pekerja kami dan semula mereka (__ME__ gantikan dengan sebuah identifier, termudah akan alamat IP):
UPDATE `pekerjaan` SET `status` = 0 WHERE `status` = 1 DAN `started_by` = __ME__;
- Menggunakan tugas kita kriteria seleksi, pilih pekerjaan dan kepada sistem kawalan yang pekerja ini berurusan dengan itu:
UPDATE `pekerjaan` SET `status` = 1, `started_by` = __ME__, `started_at` = NOW () WHERE `status` = 0 OR
(`Status` = 1 DAN `started_at`> DATE_SUB (NOW (), interval X JAM)) ORDER BY `id` ASC;
Dengan menyambar pekerjaan yang belum kembali hasil sebanyak X waktu kami memastikan bahawa semua kerja yang berjalan jika seorang pekerja menabrak atau pergi AWOL.
- Selanjutnya turun butiran pekerjaan diikuti dengan nota sendiri:
SELECT * FROM `pekerjaan` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
Setelah menyelesaikan pekerjaan kami memasukkan kami hasil nota dan menandakan tugas sebagai selesai. Ingat sebagai kerja boleh menangguhkan / resume pada bila-bila saja membolehkan untuk beberapa kekokohan dalam naskah anda. Mungkin bahawa tugas menghentikan setengah jalan melalui mengemas kini sistem kawalan kerja, sehingga memeriksa jumlah record dalam pekerjaan dan jumlah hasil disimpan kembali kepada sistem kawalan kerja akan menjadi langkah yang bijak.
Selain itu, sementara ini menunjukkan bagaimana kerja boleh dipilih dan ditapis daripada frame-query SQL anda benar-benar harus mencabut kawalan kerja anda sehingga jika anda memutuskan untuk beralih menggunakan perkhidmatan web, yang didasarkan sistem fail, XML , atau yang lain sejumlah sistem itu tidak akan menjejaskan kod di atasnya.
Job Tatarajah
Aspek seterusnya yang perlu dipertimbangkan adalah pekerjaan saiz dan konfigurasi. Dengan bermain dengan tatarajah pekerjaan kita boleh menyerang keseimbangan yang sangat baik antara kelajuan, proses replikasi, dan kehandalan. Ambil beberapa ofa senario:
- Pekerjaan mengambil 1 setiap hari untuk menjalankan: Ini bermakna bahawa para pekerja anda butuh 15 hari untuk memproses setiap pekerjaan (ingat 10% dari kekuatan untuk 2/3rds dari masa). Ini jelas bukan tatarajah bijak, saiz pekerjaan anda terlalu besar! Itu akan mengambil sekurang-kurangnya dua kali masa untuk mendapatkan pekerjaan harus diproses pekerja awal pergi AWOL (masa untuk mengambil bahawa hal itu tidak kembali hasil ditambah masa pemprosesan semula). Dalam ideal anda akan memiliki minimal satu pekerjaan penuh lebih mudah dibersihkan pada akhir setiap tempoh idle lama, bahawa cara anda menjaga pekerjaan berdetak lebih dan pada kes terburuk pekerjaan akan mengambil dua hari untuk memproses harus yang pertama hilang.
- Pekerjaan mengambil 1 minit untuk menjalankan: Ini bermakna bahawa para pekerja anda memakan masa kira-kira 15 minit untuk menjalankan setiap pekerjaan. Sementara ini pada asalnya mungkin kelihatan ideal, anda mendapatkan pemprosesan pekerjaan tambahan selama waktu makan siang, istirahat kopi, pertemuan, dll senario ini membuat kerosakan pada kawasan lain dari sistem anda dan memperkenalkan masalah sendiri. Sebagai contoh, pertama setup anda / pemprosesan nisbah masa akan pergi ke kanan bawah, sehingga kehilangan kecekapan sistem. rangkaian anda akan terus-menerus streaming maklumat kerja dengan pelbagai pekerja kakitangan frustasi yang dong hari mereka untuk bekerja sehari. Anda juga akan menambah beban lebih pada server pemprosesan pekerjaan anda karena harus mengeluarkan banyak dan banyak potongan-potongan kecil pekerjaan secara teratur. Terkini, dalam situasi ini jika pelayan pekerjaan anda turun anda akan membuat log kembali besar dari pekerjaan yang belum selesai sementara pekerjaan yang lebih besar bisa dari pemprosesan lanjutan tidak menyedari bahawa pelayan kerja adalah mengalami kesulitan.
Pada kenyataannya tidak akan ada konfigurasi satu ideal untuk tatacara grid anda, banyak bergantung pada sumber daya yang tersedia, jenis pekerjaan, keperluan kerja masa turnaround, kemampuan rangkaian, dan sebagainya. Namun beberapa pedoman akan menjadi:
- Saiz pekerjaan sehingga setiap pekerja bisa melalui sekurang-kurangnya 3-4 pekerjaan dalam jangka masa 15 jam (tempoh masa yang paling lama mungkin idle)
- Bermain dengan saiz pekerjaan sehingga waktu setup menjadi cukup signifikan dibandingkan masa pemprosesan (mengingati titik di atas).
- Jika pekerjaan tidak lengkap dalam dua kali ganda jumlah masa (mungkin kurang) anda harapkan untuk menyelesaikannya berasumsi bahawa AWOL yang hilang dan mula memproses dengan pekerja-pekerja lain. Ini bermakna anda mungkin perlu menunggu sehingga tiga kali panjang muzik pekerjaan sampai selesai (mungkin lebih lama jika pekerjaan seterusnya gagal). Anda mungkin mahu mengurangkan saat ini, tapi hati-hati tidak untuk mengurangkan terlalu banyak kerana anda mungkin mula menduplikasi tugas-tugas pemprosesan secara teratur.
- Pekerjaan harus bebas daripada keperluan luar sebanyak mungkin. The job server, for example, should only be contacted at the start and end of every job.
- Don't saturate your network, this will have two negative effects, your daytime staff will find using the network frustrating and problems may be experienced with connections timing out a problem that will only get worse as you scale your grid.
- Ensure jobs can run on your workers. If jobs become too memory intensive or disk space intensive jobs will start aborting and the only thing you'll notice is a drop in number of jobs processed with no real reason why.
Submitting Results of a Job
When submitting the results of a job it is important to check that results have not been submitted by another worker, especially if the current worker has been dormant for some time.
When results are submitted ensure that the number of results matches the number of records within the job.
As stated previously, and can not be over emphasised, build fault tolerance into job retrieval and results submission. The workers can (and most likely will) go into suspend mode at the most inconvenient of times and this needs to be catered for. Also once again abstracting away your results submission will help cater for future changes to your job control system much easier to deal with.
Review
In this section we have looked at what a job control server needs to do and how to get a very basic system set up. We discussed how to retrieve a job from the control system and how best to configure jobs to get the most our of your office grid system. To finish, a paragraph or two on submitting results back to the job control server was presented.
- A job control server manages jobs and ensures that all work units are completed
- By abstracting your job select/results submission we can change the technology of the control server without much problems
- Tatarajah pekerjaan anda untuk memastikan bahawa mereka dijalankan dengan cepat dan cekap tanpa memberi tekanan terlalu banyak pada infrastruktur rangkaian anda, dan tanpa duplikasi tugas pemprosesan secara teratur.
- Ensure that you build fault tolerance and error checking into your routines, workers can suspend and resume and the most inconvenient of times. Remember to check if results have already been submitted by another worker.
Lain kali
In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.
Komen (0) 
Apache , Pengkomputeran | 
apache , auth , pengesahan , dasar , htpasswd , mod_auth , mod_auth_digest , mod_proxy , proksi , vhost 
