1. Kelompok A :
Eka Agus Sutrisno (064.08.034)
Johan Irfan (064.08.014)
Aditia Permana (065.09.000)
2. PENDAHULUAN
Terlepas dari manejemen protocol tertentu yang
dipakai, interaksi antara manajer dan agen
mengikuti pola dasar tertentu. Bab ini
menggambarkan, bagaimana manajer dan agen
berinteraksi. Kami akan membahas timbal balik dan
dampak mendalam bahwa ada atau tidak adanya
kemampuan interface manajemen tertentu pada
aspek-aspek seperti efisiensi dari manejemen
informasi , skala manajemen aplikasi dan
performance , serta robustness terhadap kesalahan
manajemen. Pembahasan pola manajemen
didahului dari pembahasan protokol manajemen
yang sebenarnya , yang akan terjadi dalam Bab 8,
Common Management Protocols: Languages of
Management.
3. Layers of Management
Interactions
Dalam semua sistem jaringan, komunikasi yang
terstruktur dalam lapisan Ini termasuk manajemen
komunikasi. Sebelum menjelaskan ke dalam pola
pertukaran komunikasi antara manajer dan agen,
mari kita bicara singkat tentang bagaimana
komunikasi manajemen umumnya terstruktur dalam
lapisan yaitu, peran dan fungsi yang berbeda , yang
Anda akan menemukan di lapisan dari tumpukan
protokol manajemen.
Layer paling atas dari susunan komunikasi
umumnya layer aplikasi, yang menyediakan aplikasi
komunikasi dengan layanan dan communication
primitive yang dapat mereka gunakan untuk secara
langsung berkomunikasi satu sama lain.
5. Layer TRANSPORT
Layer transport pada dasarnya adalah agnostik dan independen dari
protokol manajemen ini berada di Layer 4 dari model referensi OSI dan
merupakan lapisan pertama yang menyediakan end-to-end layanan
komunikasi untuk sistem berkomunikasi
6. Layer REMOTE OPERATION
Layer remote operation menawarkan tiga fungsi yang berbeda yang
melengkapi dan melakukan layanan penting bagi lapisan Manajemen
Operasi di atas :
association control berhadapan dengan bagaimana cara mengestablish
sebuah manajemen session
remote operations support melibatkan mekanisme yang digunakan
untuk menggabungkan manajemen request dan respon
Asyncronus
Syncronus
encoding of payload data
8. Cont...
Untuk melindungi user dari operasi manajemen dari
keterbatasan, fragmentasi / reassembly funsi yang dapat
memecah PDU manajemen menjadi beberapa bagian
pada akhir pengirim dan berkumpul kembali potongan-
potongan di akhir penerima. Gambar 7-3
menggambarkan konsep ini.
Perhatikan bahwa ada kemungkinan untuk manejemen
permintaan dan respon yang sesuai. Misalnya,
permintaan oleh manajer untuk mengambil konfigurasi
subsistem dapat menjadi sangat pendek, namun respon
dikembalikan oleh agen mungkin berisi data dalam jumlah
yang besar dan karenanya menjadi sangat panjang.
Selain itu, ukuran respon sering tidak dapat ditentukan
pada saat permintaan dibuat. Tanpa fungsi fragmentasi
dan reassembly, beberapa permintaan manajemen
mungkin hanya dijawab dengan "respon yang panjang"
error
10. layer MANAGEMENT OPERATION
Konsep management operasi umumnya mereka gunakan dalam pola
komunikasi manajemen yang perlu dibedakan dari Instansiasi yang khusus
sebagai bagian dari protokol manajemen tertentu.
Lebih spesifik tentang operasi tertentu dicatat didalam manajemen informasi
yang menyertai mereka, serta parameter tambahan yang digunakan untuk
memenuhi syarat operasi. Tipe Primitive menyertakan:
Read primitif : digunakan untuk mengambil informasi manajemen. Mereka
sering disebut sebagai operasi.
Write primitive : digunakan untuk mengubah atau mempengaruhi informasi
manajemen. Mereka sering disebut set operation.
Write primitif kadang-kadang dibagi lagi menjadi Create, Delete and Modify
Operation tergantung pada apakah mereka menghasilkan creation or deletion
of logical entities (seperti perangkat subinterfaces atau endpoint koneksi), atau
apakah mereka mengubah atau memperbarui sebuah entitas logis yang sudah
ada
Event-reporting primitives : digunakan untuk mengkomunikasikan
terjadinya peristiwa tertentu dengan manajemen agen.
Less common primitives : ...
11. Layer MANAGEMENT SERVICE
mereka memgenalkan tentang tujuan management informasi khusus yang
menyediakan management service melebihi fungsi yang management
primitve berikan. Berikut ini adalah contoh dari management service
seperti:
Sebuah layanan yang memungkinkan management aplication untuk
specific types of events berdasarkan kriteria filter tertentu, seperti
semua event yang berkaitan dengan port tertentu, atau semua event
dari jenis event tertentu.
12. Manager Initiated
InteractionsRequest and
Response beralih ke cara di mana interaksi yang
Mari kita sekarang
sebenarnya antara manajer dan agen, atau manejemen
aplikasidan manage device, berlangsung. Di sini kita
melihat bagaimana manajemen operasi yang dipakai
untuk melakukan menejemen komunikasi yang efektif.
Kita mulai dengan interaksi yang diprakarsai oleh
manajer. Interaksi yang diprakarsai oleh agen merupakan
subyek dari bagian berikutnya. Pola-pola interaksi antara
manajer dan agen yang dijelaskan sebagian besar
independen dari protokol manajemen tertentu (meskipun
protokol manajemen dapat mencakup ketentuan-
ketentuan khusus untuk memenuhi sebagian dari pola-
pola), melainkan, mereka merupakan karakteristik
komunikasi manajemen secara umum dan membantu
untuk memahami bagaimana protokol manajemen yang
dipakai.
14. Cont...
Tipe permintaan yang dikeluarkan oleh manajer termasuk
minimal, parameter yang menentukan sebagai berikut:
Jenis permintaan yang dibuat
Menejemen informasi bahwa permintaan berlaku atau,
sebaliknya, parameter yang membawa informasi yang diperlukan
untuk melaksanakan permintaan
Untuk informasi tambahan misalnya, pengidentifikasi untuk
permintaan dan kredensial keamanan seperti informasi
otentikasi untuk memverifikasi identitas pemohon
Tergantung pada jenis permintaan, kadang-kadang
dengan parameter kualifikasi tambahan dapat
dimasukkan yang menentukan perilaku tambahan, seperti
apa yang harus dilakukan dalam kasus permintaan yang
awalnya gagal .
15. Information Retrieval
Polling and Polling-Based
Management umum dari permintaan /
Mungkin jenis yang paling
tanggapan menejemen interaksi melibatkan permintaan
informasi oleh manajer, di mana manajer interrogates
agen. Hal ini juga disebut sebagai polling
Pola dasar ini sangat sederhana: Manajer meminta agen
untuk bagian tertentu, atau potongan informasi
manajemen. Agen memeriksa keabsahan permintaan
tersebut dan mengambil informasi yang diminta. Agen
kemudian merespon, memberikan informasi yang diminta
dalam respon atau kode respon kesalahan yang
menunjukkan alasan permintaan tidak dapat dipenuhi.
Ketika respon terlalu besar untuk ditransmisikan dalam
satu kesempatan, mungkin perlu dikirim dalam beberapa
bagian, seperti yang ditunjukkan sebelumnya pada Figur
7-3.
16. Requests for Configuration
Information
Konfigurasi informasi permintaan manajer dapat
menginformasikan tentang logical dan physical
configuration dari perangkat. Dibandingkan dengan data
operasional dan informasi state, konfigurasi informasi
akan mengubah hanya sesekali, ketika itu terjadi,
umumnya hanya atas nama manajemen aplikasi atau
administrator sistem. Perubahan konfigurasi informasi
yang dimulai bukan oleh agen itu sendiri, tapi dari luar,
apakah itu seorang teknisi mencabut line card dari
perangkat atau manajemen mengkonfigurasi sebuah
interface. Karena perubahan sangat jarang terjadi,
informasi ini biasanya diminta jarang bukan karena
aplikasi manajemen tidak membutuhkannya, tetapi
karena aplikasi bisa menyimpan informasi ini dalam
database mereka sendiri. Selain itu, seringkali perubahan
yang dilakukan melalui sistem manajemen itu sendiri,
dalam hal ini sudah tahu tentang perubahan.
17. Requests for Operational
Data and State Information
Tipe lain dari informasi manajemen yang dapat diminta menyangkut data operasional
dan informasi state. Seperti yang telah dibahas dalam bab sebelumnya, informasi
state berbeda dari konfigurasi informasi dalam beberapa cara penting. Sebagai
contoh, dimiliki oleh perangkat yang dikelola sendiri dan tidak dapat diubah oleh
manajemen aplikasi. Sebaliknya, itu mencerminkan perangkat independen dari
kebutuhan untuk dikelola.
kasus tersebut hanya melibatkan permintaan untuk manajemen informasi , keterkaitan
pola komunikasi dan pertimbangan untuk bagaimana mengoptimalkan mereka sangat
tergantung pada jenis informasi yang diambil.
Polling sebuah perangkat dikelola untuk data operasional dan informasi state
umumnya digunakan dalam skenario seperti berikut:
Device Viewing : Sebuah remote user ingin memperoleh pandangan
real-time dari perangkat, membutuhkan snapshot dari informasi terkini.
Troubleshoting dan Diagnostic : tingkah laku tidak menentu yang telah
diamati dalam jaringan, dan aplikasi perlu untuk mendapatkan data aktif
dari perangkat untuk menentukan penyebabnya.
"Hot spot" polling: Sebuah perangkat tertentu berada di bawah
pengawasan dan pengamatan tertentu, informasi state yang disurvei
oleh karena itu berulang kali selama jangka waktu. Hal ini juga disebut
sebagai polling periodik. Dalam beberapa kasus, data yang disurvei
digunakan untuk plot kurva yang update setiap detik atau lebih, mirip
dengan memplot grafik saham selama hari perdagangan.
20. Jika tujuan state adalah polling terus menerus untuk mengamati
keadaan dari waktu ke waktu, polling efektif tetapi masih mahal.
Meskipun kadang-kadang itu adalah satu-satunya pilihan yang
tersedia, pola interaksi lebih efektif terjadi untuk meringankan
beban pada perangkat , manajemen aplikasi, dan manajemen
jaringan. Secara khusus, bukan hanya polling untuk
menginstruksikan perangkat untuk mengambil snapshot pada
interval tertentu tanpa mengirimkan permintaan setiap kali. Dua
variasi yang ada:
Hasil snapshot tersebut ditulis oleh agen ke file lokal, yang akan
ditransfer dalam jumlah besar di titik tertentu. Solusi ini cukup bila tidak
ada kebutuhan bagi data yang akan diberikan secara real time, seperti
yang ditunjukkan pada Gambar 7-7.
Snapshot akan dikirim secara otomatis ketika mereka mengambil.
Perhitungan tinggi daripada dalam kasus pertama manajemen
komunikasi pada setiap interval polling. Namun, snapshot yang
disediakan secara real time, dan tidak ada kebutuhan untuk agen untuk
menjaga snapshot di dalam file pertimbangan penting jika memori non
volatile pada perangkat adalah sumber daya yang langka (lihat Gambar
7-8).
23. Bulk Requests and
Incremental Operations
Apakah permintaan untuk manajemen informasi menyangkut data konfigurasi
atau operasional dan informasi state, ada dua pilihan untuk granularity dari
permintaan. Opsi pertama (standar, dalam banyak kasus) adalah hanya
meminta bagian tertentu dari manajemen informasi. Untuk mendapatkan
beberapa manajemen informasi. Manajemen operasi yang menyangkut satu
item pada suatu waktu juga disebut operasi tambahan (masing-masing,
permintaan tambahan). Dalam variasi, beberapa item dapat diambil dalam
permintaan yang sama tetapi masih perlu disebut secara eksplisit.
Selain pilihan tambahan, kadang-kadang ada pilihan kedua yang memungkinkan
pengambilan informasi dalam jumlah besar. Dalam hal ini, tidak setiap bagian
dari manajemen informasi secara terpisah dinamai melainkan, retrieval bulk
meminta semua informasi yang memenuhi kriteria tertentu, seperti "semua data
operasional dari card line atau semua konfigurasi informasi.
Ketika manajemen informasi disusun menjadi sebuah konsep manajemen
informasi tree , salah satu cara untuk mengambil informasi dalam jumlah besar
adalah dengan hanya meminta seluruh subtree. Operasi yang diarahkan bukan
pada setiap objek yang dikelola tertentu tetapi pada objek apapun di bawah
node induk tertentu disebut scoped. Scoping operasi tidak terbatas pada
permintaan untuk pencarian manajemen informasi , tetapi dalam konteks ini
bahwa hal itu mungkin yang paling penting. Ruang lingkup operasi umumnya
merupakan subtree misalnya, segala sesuatu yang berkaitan dengan fitur
komunikasi tertentu, seperti protokol routing, atau segala sesuatu yang
terkandung di bawah port tertentu atau subsistem komunikasi (lihat Gambar 7-
9).
25. Historical Information
Hal ini menyebabkan pola komunikasi yang berbeda dengan yang digunakan dalam hubungannya dengan konfigurasi
informasi atau data operasional dan informasi state. Meskipun pada setiap kasus hanya melibatkan pengambilan
manajemen informasi, pertimbangan untuk bagaimana mengoptimalkan pengambilan ini dan pola interaksi ini sangat
tergantung pada jenis informasi yang diambil.
Salah satu cara history informationdapat dikumpulkan adalah cukup hanya memiliki manajemen aplikasi, permintaan
reguler untuk mendapatkan informasi state. Ini adalah pendekatan yang sangat sederhana. Namun, ia memiliki sejumlah
kelemahan :
Polling overload : Memiliki sebuah perangkat polling manajemen aplikasi di seluruh jaringan setiap 15 menit dapat
menjadi tugas menakutkan dan membutuhkan banyak tenaga . Hal ini dapat dengan mudah menghadirkan aplikasi
ke batas seberapa jauh ia dapat berkembang. Selain itu, seperti yang disebutkan sebelumnya, pengulangan polling
menambahkan beban yang cukup besar pada perangkat, yang tujuan utamanya adalah untuk menyediakan fungsi
komunikasi melalui jaringan.
Robustness: pekerjaan manajemen connection dan manajemen aplikasi diperlukan pendekatan polling untuk
bekerja. Dalam setiap kasus hiccups terjadi (misalnya, karena konektivitas manajemen untuk sementara hilang atau
karena aplikasi manajemen lalu restart), siklus polling yang tidak terjawab dan celah dalam data yang dikumpulkan.
Calibration of interval lengths : Mungkin yang paling penting, histori informasi yang dikumpulkan melalui polling belum
tentu akurat karena sulit untuk menjamin polling bahwa pada perangkat yang tepat pada interval. Sebagai contoh,
aplikasi manajemen bisa terlambat dalam mengeluarkan permintaan polling, atau jaringan dapat memperkenalkan
penundaan yang bervariasi dari waktu ke waktu, menyebabkan permintaan untuk mencapai perangkat dikelola di
berbagai interval waktu. Gambar 7-10 menggambarkan masalah ini. Hasilnya adalah bahwa data yang disurvei
hanya melukis gambaran perkiraan, bukan keakuratan, dari sejarah yang sebenarnya.
Synchronization of interval start times : manajemen aplikasi biasanya menginginkan batas interval waktu dari data
historis harus sama di seluruh perangkat. Sebagai contoh, interval selalu bisa dimulai . Hal ini membuat data yang
lebih sebanding seluruh jaringan dibandingkan dalam kasus (misalnya, perangkat 1 at 12:00,, 12:15 12:30, dan
12:45; perangkat 2 jam 12:02, 12 : 17, 12:32, dan 00:47, perangkat 3 pada 12:06,, 12:21 12:36, dan 00:51, dan
seterusnya). Mencoba untuk mencapai sinkronisasi interval pemungutan suara di seluruh jaringan dengan sistem
manajemen terpusat adalah nyaris mustahil.
27. Configuration Operations
Satu perbedaan yang jelas antara pengambilan
informasi dan operasi konfigurasi menyangkut
kemungkinan untuk gagal. Karena sesuatu di
perangkat itu harus diubah, banyak hal lagi yang
bisa salah dalam melayani permintaan dari dalam
kasus ketika informasi manajemen akan diambil.
Dengan configuration request, bagaimanapun, juga
bisa membuat perbedaan apakah operasi yang
sama dilakukan sekali. Dalam hal ini, aplikasi harus
berhati-hati untuk menangani skenario yang
mungkin berbeda, seperti Gambar 7-11
mengilustrasikan.
29. Berkutat dengan file konfigurasi
Perbedaan ketiga antara manajemen interaksi untuk information
retrieval dan interaksi untuk operasi konfigurasi berakar pada cara
dimana konfigurasi informasi dimaintain pada level perangkat.
Hal ini membuat lebih mudah untuk menangani keseluruhan
konfigurasi.Sebagai contoh, permintaan untuk operasi konfigurasi
yang melibatkan 3 hal berikut:
Mempersiapkan sebuah file konfigurasi yang berisi konfigurasi yang akan
diterapkan
Men-download file ini konfigurasi pada perangkat
eksplisit memberikan perintah pada perangkat untuk beralih dari konfigurasi
saat ini ke yang baru konfigurasi dalam file baru
30. Tindakan
beberapa interaksi menyebabkan perangkat untuk melakukan
tindakan tertentu. Contohnya adalah permintaan pada perangkat
untuk me-reboot , permintaan untuk melakukan self-test, atau
permintaan untuk "ping" pada perangkat lain untuk melihat apakah
sudah tersambung satu sama lain.
Pada gambar 7-12 digambarkan, apa yang harus dilakukan oleh
seorang manajer tidak menerima respon.
31. Cont..
Pada gambar 7-13 dijelaskan tentang respon interaksi
manajemen dalam menyediakan sarana untuk memodifikasi
permintaan yang efektif dengan membagi menjadi beberapa
bagian
32. Manajemen Transaksi
Terkadang aplikasi manajemen tidak ingin mengeluarkan isu
permintaan / sepasang respon untuk setiap operasi konfigurasi
atau tindakan manajemen, melainkan bisa beberapa kelompok
perintah bersama-sama dan telah mereka jalankan bersama-sama
sebagai satu unit.
33. Cont..
Perhatikan contoh sederhana dari sebuah penyedia layanan
yang ingin penyisihan digital subscriber Line (DSL), seperti
Gambar 7-14 mengilustrasikan. jaringan yang mencakup
DSLAM tidak terlihat ke jaringan IP dan, pada dasarnya,
diperlakukan seperti kawat (Kawat yang cukup canggih, tentu
saja). Jadi untuk layanan DSL untuk bekerja, berikut ini
diperlukan:
Sambungan perlu diatur, antara DSLAM dan agregasi router-lebih
tepatnya, antara port jaringan terhadap DSLAM dan DSLAM terhadap
router agregasi.
Pada DSLAM, port untuk pelanggan harus bersifat cross-connected dengan
network yang port terhubung dengan koneksi ke router agregasi.
35. Agent-Initiated Interactions: Events and Event-
Based
Management
Pada bagian ini, agent memulai komunikasi dan
mengirimkan pesan pada manajer untuk membawa
sesuatu ke Perhatian manajer, biasanya mengenai
beberapa jenis kejadian atau peristiwa yang telah
terjadi.
Pada dasarnya, pesan acara sesuai dengan
interupsi yang membantu manajer melakukan
pekerjaan mereka agar lebih baik.
Pesan acara kadang-kadang juga disebut sebagai
Trap , khususnya dalam konteks SNMP. Sebuah
quick note pada terminologi: Sebenarnya, peristiwa
aktual yang terjadi di dunia nyata membutuhkan
harus dibedakan dari pesan yang digunakan untuk
berkomunikasi acara tersebut.
36. Event Taxonomy
peristiwa yang digunakan untuk berbagai tujuan,
memberitahu manajer berbagai jenis kejadian. Dengan
demikian, mereka dapat diklasifikasikan menjadi
beberapa kategori. Yang paling umum yang adalah
sebagai berikut:
Alarm
Configuration changes event
Alarm Treshold-crossing
Logging event
Peristiwa Logging dapat berhubungan dengan berikut:
- Operator Activity
- System Activity
- Activity on the network and services
37. Alarm
Komunikasi sebuah Alarm memberitahukan bahwa beberapa
peristiwa tak terduga telah terjadi yang mungkin memerlukan
perhatian manajemen. Sebagai contoh:
Sebuah kartu di router mungkin telah gagal, membutuhkan kartu secara fisik
diganti.
Suhu mungkin terlalu tinggi dan ada risiko kerusakan fisik pada peralatan.
Sebuah port mungkin telah mendeteksi sesuatu yang tak terduga yang
kemungkinan adalah adanya konektivitas di luar jalur.
Alarm harus mencakup informasi tambahan berikut:
Jenis alarm adalah jenis aktivitas yang terjadi.
Tingkatan alarm menunjukkan dampak alarm-misalnya, apakah itu
mempengaruhi layanan.
38. Configuration- Change
Event
Configuration change event menginfokan bahwa
perubahan konfigurasi telah terjadi pada sebuah device
Memantain database yang akurat pada perangkat pada saat
itu juga dan mengkonfigurasi jaringan sangat penting untuk
banyak aplikasi
Idealnya, configuration change event meliputi informasi
tambahan seperti berikut:
The configuration chnage that was aplied
The originator of the change request
Therequest identifier
40. Threshold- crossing alert
Treshold-crossing alert mengindikasikan pada manajemen
sistem bahwa monitor MIB melihat adanya objek atau
sebuah variabel yang melewati batas dari sebuah jalur
seharusnya
41. Cont..
TCA harus menambahkan beberapa informasi seperti :
Memonitoring Variabel dari threshold MIB untuk
mencegah adanya treshold crossing
Memberikan nilai pada tingkatan threshold
Memberikan info, apakah threshold ini bersih atau
ada objek yang tidak seharusnya ada
42. The case for event-based
management
Adanya 2 fundamental communnication pattern pada
monitoring jaringan
Polling based
Event based
Beberapa rangkuman aspek pada management pattern
Number of required communnication exchange for a given task
Timeliness
Reques-processing capacity on the managed device
Wastefulness
Available management bandwidth
Management aplication scale
43. Reliable events
Pada manajemen aplikasi adanya catatan semua kejadian
pada semua perubahan harus ada dan dilaporkan melalu
pesan dan tidak ada kejadian yang terlewatkan inilah tujuan
dari reliable events
Ada beberapa teknik yang digunakan dalam pengaplikasian
reliable events ;
Menggunakan reliable transport protocol over
Menambahkan urutan nomer pada infromasi dan memutar ulang
peristiwa yang telah tercatat
Memerlukan acknowledgement dari sebuah kejadian
44. Rangkuman
Management pertukarandiantara manajemer dan agent
mengikuti patterns tertentu
Kategori penting dari interaksi patterns termasuk diantaranya
adalah
Retrieval of configuration and status information
Provisioning of device parameters
Collection of performance snapshots
