Kinerja redundansi dari Virtual Network Solutions

Fabian Koch ABB Kai T. Hansen ABB

Corporate Research Penelitian Perusahaan
Wallstadter Straße 59 68526 Bergerveien 12
Ladenburg N-1375 Billingstad
Jerman norway
Fabian.Koch@de.abb.com Kai.Hansen@no.abb.com

Abstrak

Artikel ini membahas berbagai cara untuk mendapatkan redundansi Redundansi dapat diimplementasikan dalam berbagai cara tergantung

untuk sistem kontrol berbasis Ethernet dan persyaratan yang harus dari kebutuhan dan aplikasi yang membutuhkannya. Untuk gambaran dan

dipenuhi. Ini laporan hasil pengujian dari Common Alamat Redundancy contoh yang berbeda melihat ref. [1], [2] dan [3].

Protocol (ikan mas) dan analisis untuk aplikasi yang solusi ini layak.
Gambar 1 menunjukkan gambaran dari sebuah pabrik proses yang khas
dengan berbagai tingkat jaringan. Setiap

tingkat komunikasi memiliki persyaratan yang khas sendiri. Pada tingkat

1. pengantar perangkat, fieldbuses dan bus milik

solusi adalah yang paling umum hari ini, namun Ethernet mulai
digunakan pada tingkat ini. Fungsi yang paling penting di sini adalah
Ethernet semakin digunakan lebih banyak dan lebih dalam otomasi
lokal kontrol loop tertutup. Untuk aplikasi industri proses khas loop
industri. Salah satu persyaratan, yang penting dalam sistem industri,
harus menjamin waktu reaksi pada beberapa ratus milidetik, tetapi ada
adalah keandalan sistem kontrol dan ketersediaan akses ke kontroler
juga aplikasi di mana kali lingkaran lebih cepat harus diperoleh. Untuk
dan nilai-nilai lapangan dari operator manusia. Ketersediaan dapat
aplikasi seperti Substation Automation (perlindungan daya listrik dan
diperoleh dengan berbagai bentuk redundansi.
kontrol) dan Motion Control, loop dari beberapa milidetik mungkin
diperlukan. Dalam kasus seperti itu tidak mungkin untuk
memanfaatkan solusi redundansi yang digunakan di kantor atau web
aplikasi di mana keras tanggapan real-time yang cepat tidak begitu
penting.
workstation wor kstation

1 - beberapa 100 c omputers

tingkat perusahaan
Pada tingkat kontroler pada Gambar 1 juga ada nomor
dari keras waktu sebenarnya Persyaratan untuk
Server komunikasi dari controller ke controller. Ini adalah non-lokal loop kontrol
tertutup, yang biasanya memiliki persyaratan dari beberapa ratus
tingkat kontrol
milidetik. Di sini juga sulit untuk menggunakan solusi standar dengan
cara yang sederhana. Untuk mendapatkan redundansi kabel pada
1 - beberapa 100 controller Server
tingkat ini ada beberapa solusi proprietary yang baik, lihat ref. [4], [5],
controll er pengawas [6], [7] dan [8].

tingkat evice D
Namun, di Enterprise tingkat itu
hirarki komunikasi, persyaratan real-time tidak sekeras untuk tingkat
perangkat dan tingkat kontrol. Setidaknya untuk beberapa aplikasi pada
tingkat Enterprise dapat diterima untuk menggunakan solusi redundansi,
yang memungkinkan ketersediaan tinggi tetapi yang tidak memenuhi
sensor s actuator s perilaku real-time yang ketat. Ini bisa menjadi aplikasi dengan HMI

1000 - 100 000 sinyal

(Human Machine Interface) yang misalnya visualisasi gambar tren,
aplikasi manajemen aset atau mengimplementasikan antarmuka web
untuk interaksi perangkat.

Gambar jaringan industri 1. Proses

1-4244-0681-1 / 06 / $ 20,00 '2006 IEEE 328

 Di beberapa area aplikasi solusi tersebut mungkin juga diterima
untuk penanganan alarm dan proses grafis.
2. Standar solusi perangkat redundansi
Kami menangkap kembali salah satu teknik yang digunakan dalam area
aplikasi lain seperti redundansi firewall, untuk menerapkan perangkat
redundansi. Idenya adalah dengan menggunakan satu alamat IP virtual
untuk beberapa node berlebihan. Satu node biasanya menjawab pada
alamat ini, tetapi dalam kasus kegagalan, kedua (atau ketiga) node akan
menjawab bukan simpul utama. Gambar 2 menunjukkan sketsa dari sistem
ini. Berikut node A dan B keduanya menyediakan fungsi dan layanan yang
sama yang dapat digunakan terhadap serta diakses dari node C dengan
cara yang sama. A dan B memiliki alamat IP yang berbeda tetapi mereka
memiliki alamat IP ketiga sebagai alamat virtual yang keduanya dapat
diakses pada. Node A adalah simpul utama dan dalam situasi yang normal
aliran data adalah sebagai sketsa pada gambar dengan panah putus-putus.
Jika node A gagal, node B
akan menemukan ini karena berhenti dalam pesan pengumuman terus
dikirim oleh A (ditandai dengan bentuk gelombang pada gambar). B
kemudian akan membalas pada pesan dari C dan aliran data seperti
yang ditunjukkan oleh panah putus-putus. Node B juga akan
mengirimkan menyimpan pesan hidup. Proses failover
benar-benar
transparan ke node C, yang hanya berbicara ke alamat IP virtual.
SEBUAH B C
B C
Gambar 2. Perangkat redundansi dengan IP virtual dan menjaga
sinyal hidup
Ini adalah prinsip yang digunakan dalam protokol seperti HSRP
(Hot Standby Router Protocol oleh ref Cisco. [10]), VRRP (Virtual
Router Redundancy Protocol oleh ref IETF. [11]), NSRP (Net Layar
redundansi Protokol oleh Juniper ref. [12]), Heartbeat ref. [13] dan di
CARP (Common Alamat redundansi Protokol oleh OpenBSD ref. [14] [15]).
329
3. karper
Pada akhir tahun sembilan puluhan, IETF mengeluarkan standar
untuk redundansi disebut VRRP (RFC 3768 [9]) meskipun Cisco
mengklaim bahwa itu tercemar dengan beberapa Paten mereka untuk
HRSP. Jadi itu tidak mungkin untuk mengimplementasikan VRRP ke
dalam perangkat lunak opensource tanpa harus berurusan dengan
isu-isu paten. Itulah alasan mengapa para pengembang OpenBSD
dibuat CARP sebagai alternatif gratis untuk VRRP. Protokol baru dapat
digunakan dengan IPv4 dan IPv6, dan menggunakan SHA-1 untuk
kriptografi menandatangani paket untuk keamanan. Sedangkan
pelaksanaan itu sendiri berbeda dari VRRP, CARP dasarnya melakukan
hal yang sama, yang menciptakan virtual IP untuk beberapa host. Untuk
mengirim keep paket hidup untuk semua host dalam rantai redundansi,
menggunakan IP multicast. Kebutuhan alternatif bebas paten untuk
VRRP menjadi jelas ketika beberapa proyek opensource dilaksanakan
karper bahkan sebelum spesifikasi yang nyata ada, terlepas dari
implementasi OpenBSD. Sejauh ini
sana adalah userspace sebuah
pelaksanaan ucarp, tersedia untuk Linux, OpenBSD dan NetBSD. Dan
ada versi kernel untuk untuk FreeBSD, NetBSD dan OpenBSD.
Seluruh proses pembangunan didampingi oleh ironi biasa dan
sarkasme dari pengembang OpenBSD, yang menyatakan: “ w hen kita
mengajukan petisi IANA, tubuh IETF mengatur "resmi" nomor protokol
internet, untuk memberikan angka untuk ikan mas dan pfsync
permintaan kami ditolak. Akibatnya kami terpaksa memilih nomor
protokol yang tidak akan bertentangan dengan apa pun dari nilai, dan
memutuskan untuk menempatkan ikan mas di IP protokol 112.”[16] ( dengan
standar IANA, IP protokol 112 dicadangkan untuk VRRP)
4. tes pengukuran kinerja
Ada sedikit atau tidak ada tolok ukur kinerja yang tersedia untuk
berbagai protokol. Jadi kita telah melakukan tes untuk solusi CARP,
yang kami laporkan di sini. Tes setup diberikan pada Gambar 3
Gambar 3. Uji Pengaturan
 Untuk tes yang sebenarnya, kantor 3com menghubungkan 100Mbit
Ethernet hub digunakan dengan 4 perangkat yang terhubung ke itu.
Satu host hanya digunakan untuk memantau lalu lintas dengan halus [17],
salah satu digunakan untuk tes akses selama failover, dan dua PC
industri menjalankan Linux tertanam, berdasarkan Debian GNU / Linux,
yang digunakan sebagai server berlebihan. Server berlebihan
menggunakan Linux Kernel dari kernel 2.6 dan versi 1.1 dari ucarp.
Mereka berdua juga menjalankan web server apache2 termasuk
halaman web dengan ulang otomatis pada satu interval kedua. ucarp
dimulai dengan -P (mendahului) argumen, sehingga tuan rumah
pertama mengirimkan paket karper langsung menjadi master. Ethereal
menangkap paket Ethernet dan waktu-prangko mereka. Hal ini juga
dapat menggambar diagram dari skenario yang berbeda. Pada Gambar
4 skenario yang diberikan. Skenario ini menunjukkan interaksi antara
perangkat pada Gambar 3 ketika master dihapus dari jaringan, dan
cadangan mengambil alih fungsi tersebut.
4). Setelah mencolokkannya kembali master dibutuhkan kembali tempat itu
langsung (putus-putus lingkaran). Beberapa lalu lintas ARP muncul selama tes,
karena ucarp tidak dikonfigurasi untuk menggunakan alamat MAC virtual,
sehingga ARP cache harus diperbarui selama peralihan a.
Gambar tes 4. failover Pertama
Halus mengakui paket CARP sebagai VRRP, karena jumlah
protokol yang sama (lihat di atas). Jadi untuk menghindari
kesalahpahaman “VRRP” diganti dengan
330
“CARP” di Angka. Juga mencatat bahwa plot halus entri baru untuk
setiap protokol muncul, sehingga beberapa IP muncul beberapa kali di
tes kedua Figures.The terdiri dari mengirimkan paket ping ke alamat IP
virtual pada selang waktu satu detik. Dalam skenario ini, PC kedua
pada jaringan, 10.49.65.42 mengirimkan permintaan ping ke IP virtual
host berlebihan. Selama dua switchovers (mencabut dan replugging
master), hanya satu balasan hilang dalam proses failover,
masing-masing. Kali ini deadratio dikonfigurasi dua detik. Pada
Gambar 5 paket CARP yang ditunjukkan pada Gambar 4 tidak
ditampilkan untuk alasan kejelasan. Lingkaran penuh dan putus-putus
menunjukkan kali failover.
Gambar 5. ICMP Ping Uji
Skenario tes ketiga menggunakan PC tes untuk browsing website yang
menyegarkan setiap detik. Selama peralihan ini, PC tes mengirimkan tiga
transmisi ulang dari permintaan HTTP GET dan sekitar 1,4 detik berlalu
sampai tuan rumah baru menjawab permintaan seperti yang ditunjukkan
pada Gambar 6 (lingkaran putus-putus
menunjukkan gagal http
komunikasi, lingkaran penuh menunjukkan failover).
Sejak CARP hanya menyediakan virtual IP dan saklar atas, koneksi
TCP tersesat dan harus reinitiated jika salah satu host tidak menerima
data tanpa sambungan baru bersih melalui jabat tangan tiga cara-.
Dengan beberapa cara status koneksi sinkronisasi antara server
berlebihan, masalah ini dapat diselesaikan. Dengan cara ini, cadangan
memiliki tabel koneksi yang sama. OpenBSD menggunakan pfsync
untuk itu; Linux memiliki Ct_sync [8].

Gambar 6. HTTP GET Uji
Waktu failover, ketika beralih dari master untuk cadangan
ditentukan oleh parameter deadratio dalam pelaksanaan ucarp.
Gambar 7 menunjukkan waktu failover selama 14 switchovers dari
master untuk cadangan. Tes ini diulang 14 kali untuk mendapatkan
beberapa perkiraan jitter yang diharapkan dalam aplikasi tersebut.
Waktu yang ditampilkan menunjukkan waktu antara paket karper
terakhir dari master dan paket CARP pertama dari cadangan sebagai
master baru. Rata-rata jitter adalah 15,7 milidetik lebih parameter
deadratio digunakan.
kali peralihan
3,019s
3,018s
3,017s
3,016s
3,015s
3,014s
3,013s
3,012s
Gambar 7. waktu peralihan di failovers dengan tiga deadratio
panjang kedua menunjukkan jitter
Dengan rekomendasi, parameter deadratio harus ditetapkan untuk
tiga kali nilai frekuensi iklan. Dalam pelaksanaan ucarp frekuensi ini
hanya dapat diatur untuk minimal satu detik. Jika deadratio ini juga
diatur untuk hanya satu detik dalam harapan untuk kali peralihan lebih
cepat, rantai redundansi dimulai kondisi lomba perulangan, karena
sedikit jitter. iklan membutuhkan hanya sedikit lebih dari satu detik
untuk
331
mendapatkan ke kawat, sehingga cadangan mengasumsikan master adalah mati
dan mengambil alih. master mengambil kembali atas dengan paket karper
berikutnya dan loop dimulai lagi.
Pelaksanaan OpenBSD memiliki kemampuan untuk mengatur
frekuensi iklan ke nol dan menggunakan apa yang disebut iklan
condong (advskew) untuk mengontrol kali paket pada resolusi yang
lebih baik. Maka hasil waktu failover dari perhitungan:
3 * (advbase + (advskew / 255))
Menjaga keseimbangan antara terlalu banyak lalu lintas dan switchovers
cepat yang tersisa untuk pengguna. Misalnya dengan
advbase = 0 dan advskew = 64 paket akan dikirim setiap 0,25 detik dan
peralihan akan mengambil 0,75 detik. Namun sebagai implementasi
ucarp tidak mendukung frekuensi iklan di bawah satu detik, ini hanya
bekerja dengan versi OpenBSD saat ini.
5. Kesimpulan
Kami telah menunjukkan bahwa protokol karper tidak menyediakan
mekanisme failover yang stabil yang dapat dimanfaatkan dalam sejumlah
aplikasi real-time yang lebih lembut dalam pengaturan industri. The
gagal-over kali terus stabil selama tes yang telah kita lakukan, menjadi
14-18 milidetik atas parameter set dalam kode ucarp ketika menjalankan
di Linux. Kami percaya bahwa untuk aplikasi industri tanpa persyaratan
untuk peralihan yang sangat cepat, karper dapat menjadi salah satu
pilihan untuk memberikan solusi yang baik dan biaya yang efektif untuk
ketersediaan tinggi mengenai akses ke sistem kontrol.
Sebuah implementasi baru dari ucarp yang akan memberikan solusi
dengan kali failover secara signifikan lebih kecil dari satu detik, akan
memungkinkan berbagai aplikasi baru yang juga dapat mencakup beberapa
sistem kontrol.
Referensi
[1] H. Kirrmann, Kesalahan Computing Toleran di Industri
Otomatisasi, Kuliah mencatat ABB Corporate Research / ETH Swiss,
2 nd Edisi 2005. [2] Artikel di Issue khusus pada Keandalan, IEEE
Spectrum,
Vol. 18, No 10, Oktober 1981. [3] KT Hansen, Redundansi
Ethernet di Industri
Otomatisasi, ETFA 2005, hal 941-948. [4] http://www.hirschmann.com
[5] http://www.ruggedcom.com/ [6] http://www.ontimenet.com [7] Telekomunikasi
Inggris: Jaringan Ekstrim
otomatisasi Ethernet laporan Evaluasi perlindungan switching,
Laporan Teknis, ref 80056, 2003. [8] S. Shah, M. Yip. Ethernet
Perlindungan Extreme Networks' Otomatis (PBK). Jaringan
Kelompok Kerja Permintaan Komentar: 3619, 2003. [9] Virtual
Router Redundancy Protocol (VRRP),
http://www.ietf.org/rfc/rfc3768.txt
[10] Cisco Hot Standby Router Protocol (HSRP),

http://www.ietf.org/rfc/rfc2281.txt [11] Virtual Router

Redundancy Protocol (VRRP),
http://www.ietf.org/rfc/rfc3768.txt [12] Juniper Networks, Konsep
& Contoh, Volume 11:
Ketersediaan tinggi, ( NSRP)
http://www.juniper.net/techpubs/software/screenos/scre enos5.3.0 /
ce_v11.pdf [13] Heartbeat, http://linux-ha.org/Heartbeat [14] Pedoman
OpenBSD Programmer, umum Alamat

Redundansi Protocol (ikan mas),

http://www.openbsd.org/cgibin/man.cgi?query=carp&sektion=4 [15] R.
McBride, Firewall Failover dengan pfsync dan ikan mas,

http://www.countersiege.com/doc/pfsync-carp/ [16] http://www.openbsd.org/lyrics.html#35

[17] http://www.ethereal.com

332