Memanage Layanan Aplikasi melalui Layanan Penyedia Jaringan

Naija

, Setyo

, Chouijah

Universitas Bina Nusantara
Kemanggisan


ABSTRAK

Tulisan ini mengusulkan sebuah pendekatan untuk memanage IP berdasarkan layanan dan
aplikasinya. Mendeskripsikan bagaimana seseorang dapat memperbesar jaringan yang telah
ada dan paradigma manajemen sistem ke Network Service Providers (NSP). Penulis
mengenalkan konsep dari layanan manajemen domain dimana ini adalah virtual domain yang
dibuat dari physical monitor domain di network management layer. Layanan manajemen domain
membentuk dasar untuk memanage kesalahan, performa, dan tingkat layanan yang berhubungan
dengan penawaran layanan aplikasi.

Kata kunci : Aplikasi Manajemen, Analisis Dependency.

I. PENDAHULUAN

Sepanjang dasawarsa terakhir, layanan koneksi paket telah menjamur menjadi trend
market. Network Sevice Provide (NSP) yang dikenal juga sebabai Internet Service Provider
(ISP) adalah perusahaan yang menyediakan akses jaringan backbone yang secara geografis
tersebar di berbagai lokasi. NSP seperti IBM Global Network mendefinisikan sebuah jaringan
virtual privat dapat menghubungkan lokasi yang berbeda untuk saling bertukar informasi.
Pelanggan ingin memiliki semacam layanan internet sejak harga memasang koneksi ini lebih
murah dibandingkan dengan menyewa kabel dan kontrak yang bagus dengan adanya pemakaian
bandwitch. Sejak tahun 1990an, bandwitch semakin meningkat dan menjadi sebagai komoditas
umum, yang akhirnya banyak NSP ikut dalam persaingan. NSP secara berangsur- angsur
bergerak melewati layar jaringan untuk membangun dan menawarkan layanan aplikasi. Dari titik
pandang NSP, ketentuan layanan aplikasi telah membawa tantangan yang baru, yaitu bagaimana
mengelola layanan ini sehingga ketersediaan yang tinggi selalu terjamin. Umumnya, NSP sudah
memiliki infrastruktru manajemen jaringan yang dikembangkan dengan baik untuk
mengoperasikan jaringan fisik mereka yang terdiri dari server, switch, router, dll. Jadi tujuan
yang sangat penting adalah untuk memanfaatkan infrastruktur jaringan yang ada dan
meningkatkan layanan aplikasi manajemen. Penelitian telah menunjukkan bahwa suatu aspek
kritis dari penentuan masalah dalam lingkungan komplek adalah identifikasi dan representasi
dari dependensi. Jurnal ini menjelaskan arsitektur yang menunjukkan isi di atas dengan
memperluas infrastruktur manajemen dengan kemampuan layanan aplikasi manajemen.
Bagian 2 memberikan gambaran jaringan penyedia layanan khas dan manajemen
arsitektur. Bagian 3 memperkenalkan konsep layanan aplikasi dan mendefinisikan konsep
layanan manajemen domain. Bagian 4 menjelaskan repository berdasarkan metodologi untuk
menentukan dan menganalisi dependensi. Dependensi umum yang digunakan sebagai input dari
arsitektur layanan manajemen aplikasi dijelaskan pada bagian 5. Bagian 6 berisi tentang
kesimpulan dari jurnal ini dan menyajikan isu- isu yang lebih mendalam untuk penelitian.

2. NSPs: Perpindahan dari hanya sekedar Bandwitch ke layanan nilai tambah.
IBM Global Network memiliki jumlah pengguna yang tersebar di 800 kota dan 100
negara. Menawarkan aplikasi IP dan SNA dan layanan konektivitas melalui Frame Relay dan
ATM. Dalam lingkungan jaringan, scenario khas untuk layanan aplikasi jaringan terdiri dari 3
entitas berbeda : lingkungan tempat pelanggan (CPE), luas wilayah jaringan, dan aplikasi
hosting.
Dalam manajemen jaringan tradisional, pendekatan yang umum dilakukan adalah
mempartisi fisik lingkungan jaringan ke dalam apa yang dikenal sebagai monitored domains,
yang masing- masing dibawah pengawasan manajemen sistem. Mereka didefinisikan menurut
pertimbangan topologi. Sebuah layangan aplikasi,terdiri dari komponen terdistribusu seperti
server database, nama domain server, bermacam- macam program berbahaya, dll, tergantung
pada kinerja dan status sumber daya yang dimiliki oleh beberapa domain. Jurnal ini
memperkenalkan konsep layanan manajemen domain yand dibangun dari sumber daya. Mereka
membentuk dasar pemantau informasi untuk mengelola kesalahan, kinerja, dan perjanjian.
Untuk jaringan yang besar dengan banyak domain monitor, manajemen terpusat menjadi
penghalang dari jumlah data. Oleh karena itu, ini adalah percobaan umum untuk
mengimplementasikan manajemen hierarki, setiap bagian bertanggung jawab atas serangkaian
domain, seperti yang ditunjukkan oleh batas titik- titik pada gambar 1. Layanan manajemen
standar platform, sepeti TME Tivole, Trool, HP Open View, dan Cabletorn menyediakan
hierarki khusus.
Manajer tingkat menengah dapat dianggap sebagai dual-peran entitas (agent dan
manager) yang memproses data raw menjadi informasi manajemen yang berarti. Dari pandangan
arsitektur manajer tingkat menengah muncul sebagai pelebaran SNMP agent ke tingkat atas dari
Network Operations Center (NOC) stasiun managemen. Fungsi yang dilakukan oleh MLM
antara lain :
- Pemungutan suara agen SNMP dalam domainnya, variable yang sedang dipilih dan
frekuensi pilihan ditentukan oleh kebijakan yang secara berkala diatur oleh MLM, untuk
mencerminkan perubahan di topologi.
- Penerimaan traps dari SNMP agen, penyaringan berdasarkan aturan yang didefinisikan
oleh top level manager dan didownload ke MLM.
- Penyimpanan dari data lokal ke database. Data ini disimpan secara berkala dikirim ke top
level manager dengan menggunakan beberapa protokol transfer data missal seperti FTP.
Data ini kemudian dianalisa dengan aplikasi yang terletak di top level manager untuk
menghitung statistic SLA, membuat histogram, membuat tren laporan, dll.
- Penyaringan dan penyampain traps yang terpilih ke top level manager dan kesalahan dari
layanan manajemen. Di scenario kami, peristiwa tersebut diterima oleh Tivoli Enterprise
Console (TEC) yang memungkinkan seorang manajer jaringan menentukan aturan dasar,
bahkan tindakan otomatis untuk deteksi kesalahan efisien dan resolusi.
- Menjalankan protokol cadangan sehingga jika salah satu MLM turun, lainnya dapat
mengambil tanggung jawab sampai MLM yang turun tadi bekerja lagi. Dalam lingkungan
kita, toleransi kesalahan dan ketersediaan mekanisme telah diterapkan di MLM yang
didesain memiliki cadangan.
Saat ini, jaringan data yang paling besar telah memiliki sistem manajemen operasional yang
dapat diterapkan oleh model ini. Semakin dan semakin banyak penyedia jasa jaringan
menawarkan layanan aplikasi dengan tambahan untuk memperluas konektivitas IP, hal ini
penting untuk dipahami bagaimana suatu infrastruktur jaringan manejemen yang ada dapat
ditingkatkan untuk mendukung fungsi manejemen dari layanan aplikasi.

3. Persyaratan untuk Layanan Aplikasi Manajemen.
Secara umum, layanan aplikasi disediakan oleh server farms baik itu dimiliki sendiri dan
dioperasikan sendiri atau oleh pihak ketiga. Setiap pelanggan dari layanan aplikasi berharap
untuk mendapatkan pemberitahuan dan pembenaran tindakan dari penyedia layanan ketika
aplikasi ini mengalami kesalahan atau masalah kinerja. Kualitas dari tindakan pembenaran
dispesifikasikan di SLA antara pelanggan dan penyedia layanan. Untuk memberikan end-to-
end manajemen aplikasi untuk setiap pelanggan, penyedia layanan harus membangun sistem
layanan manajemen sebagai tambhan unuk sistem operasi manajemen jaringan yang
bertujuan untuk menyediakan fungsi kunci berikut :












Gambar figure 1
- Analisa penyebab dasar : menggambarkan status dari suatu servis pelanggan tertentu,
memiliki cara yang sama untuk melihat status dari sumbernya. Interface tatap muka ini
seharusnya menyediakan fasilitas drill down seperti, ketika muncul masalah, operator
dapat melewati bagian layar bawah ke bagian sumber daya jaringan di mana layanan
diadakan.
- Dampak analisa : ketika sumber daya turun, tentukan layanan dan pelanggan apa saja
yang terpengaruh. Informasi yang diperoleh melalui analisis ini juga sangat berguna
untuk jadwal maintenance.

Persyaratan ini diilustrasikan dengan contoh gambar di Figure 1, yang menggambarkan
konstituen penting dari layanan yang ditetapkan melalui layanan penyedia jaringan. Tiga
pelanggan yang saling terhubung satu sama lain dengan virtual frame relay sirkuit. Dua
server farms, dipelihara dan dikelola oleh penyedia layanan, menawarkan macam-macam
layanan aplikasi ke pelanggan. Contohnya, pelanggan dapat mensubscribe ke layanan
penyedia hosting, dimana catalog layanan on-line mereka dikelola oleh penyedia layanan.

Intra- System Depedensi terjadi di satu sistem, depedensi ini menunjukkan apakah
layanan yang spesifik membutuhkna layanan lain yang diinstal pada sistem yang sama.
Inter- System Depedensi yang terletak di antara layanan yang berbeda sistem dan
memiliki kunci yang penting untuk penentuan masalah end-to-end. Tipe Inter sistem
depedensi ada di antara client dan server layanan yang diberikan contohnya NFS client hanya
dapat bekerja jika server peer NFS berfungsi.
Bagaimanapun juga, sistem manajemen saat ini tidak dapat menangani layanan depedensi
karena domain topologi untuk manajemen jaringan berbeda sebagian besarnya dari layanan
manajemen domain w.r.t jumlah dan dinamika dari objek yang dikelola. Kegiatan yang biasa
dilakukan oleh NSP adalah mendefinisikan sebuah komponen untuk setiap pelanggan yang
mengandung semua sumber dari layanan subscribed (PVC, komponen jaringa, server,
aplikasi). Meskipun saat ini pelanggan focus pada aplikasi, layanan, dan jaringan, kita
memiliki kekurangan yang significan :
- Sumber daya ditugaskan untuk melihat secara manual oleh operator dan tidak automatis
sistem manajemen.
- Penempatan ikon manual dalam pandangan adalah tidak terbatas, rawan kesalah, dan
cenderung untuk menghasilkan data yang tidak konsisten.
- Seperti yang telah dijelaskan di bagian 1, manfaat utama untuk NSP berasala dari
kenyataan bahwa sumber daya (seperti router, server, firewall, dll) dibagi antara
pelanggan yang berbeda, sehingga memaksimalkan penggunaan sumber daya.
Untuk menghindari kekurangan ini ketika sedang mampun menyediakan list fungsi
layanan fungsi manajemen di atas, kita membutuhkan sebuah metodologi yang
mengijinkan kita untuk menetapkan :
- Model ketergantungan yang mewakili hubungan sumber daya ke tiap-tiap anggota.
Contoh ketersediaan NFS dan DFS tergantung pada layanan IP yang tersedia dari
lingkungan pelanggan, yang pada gilirannya tergantung pada berfungsinya akses router
dan PVC.
- Satu set dari semua sumber yang ada di lingkungan yang mempengaruhi layanan tersebut
baik secara langsung maupun tidak langsung. Contohnya, CARs, SARs dan PVCs yang
menyediakan IP konetivitas antara lokasi pelanggan dan server farm.
Kontribusi sumber daya ke fungsi dari layanan aplikasi ikut ke dalam domain fisik yang
berbeda, masing- masing di bawah lingkup pemantauan MLM. Di gambar 1, MLM1, MLM2,
MLM3 memonitor sumber daya yang perlu beroperasi atas isi hosting layanan. Satu
persyaratan kunci untuk arsitektur manajemen kami adalah dapat berhubungan secara logis
antara layanan manajemen agen dengan MLMs yang relevan, sehingga informasi yang
penting dapat segera dikirim.


4. Analisis Ketergantungan : Suatu pendekatan pragmatis berbasis repository
Analisis pada bagian sebelumnya telah menunjukkan bahwa persyaratan utama untuk
manajemen otomatis dari layanan aplikasi terdistribusi adalah memiliki catatan dari
ketergantungan mereka pada layanan dan sumber daya lapisan yang ada di bawahnya. Model
layanan abstrak telah digunakan untuk mengalamatkan masalah ini, namun pendekatan ini
membutuhkan pengumpulan dan penggalian dari jumlah besar data. Pada bagian berikut ini, kita
akan mendeskripsikan pendekatan pragmatik untuk daftar ketergantungan yang dapat disadari
pada berbagai sistem operasi yang banyak digunakan tanpa membutuhkan detail dari perangkat
manajemen dari layanan aplikasi dan jaringan.
Selanjutnya, meskipun beberapa penelitian sebelumnya dan upaya standarisasi tidak ada
solusi layanan aplikasi manajemen yang tersedia di pasar. Masalah utama adalah bahwa
manajemen aplikasi yang menyeluruh menuntut sejumlah besar informasi manajemen, sehingga
membentuk sebuah upaya perkembangan tambahan pada pengembang aplikasi. Contoh yang
baik untuk hal ini adalah Application Management Specification (AMS) yang menyediakan
standar terbuka untuk menjelaskan informasi manajemen yang dibutuhkan untuk
mendistribusikan aplikasi. Saat AMS mengidetifikasi sebuah set informasi manajemen yang
biasa untuk beberapa jenis aplikasi dan pengertian dari mengkhususkan hal tersebut
menggunakan file pendeskripsi aplikasi, pengembang aplikasi harus menyediakan perangkat
yang cocok.




4.1 Repositori Informasi SIstem
Mengetahui fakta bahwa sebagian besar layanan aplikasi berjalan pada sistem berbasis UNIX
dan Windows, ada baiknya menganalisis sejauh mana informasi tentang aplikasi
dan layanan juga sudah termasuk dalam sistem operasi. Ide pokok adalah sebagai berikut : jika
memungkinkan untuk mendapatkan sejumlah informasi yang beralasan dari sumber ini,
kebutuhan akan perangkat aplikasi tertentu dapat dikurangi. Pendekatan kita mengenali fakta
bahwa administrator sistem dengan sukses menggunakan aplikasi dan layanan tanpa memiliki
akses tentang detail perangkat manajemen aplikasi tertentu.
Sistem Windows NT/95/98 dan implementasi UNIX seperti IBM AIX dan LINUX
memiliki repositori yang telah ditanamkan yang menjaga jalan dari paket software yang diinstal,
fileset, dan versinya. AIX Object Data Manager (ODM), Windows registry, dan LINUX Red
Hat Package Manager (RPM) merupakan contoh dari seluruh sistem konfigurasi repositori. Pada
makalah ini, kita akan terfokus pada ODM. Namun, pendekatan kita juga dapat digunakan oleh
repositori lainnya.
Biasanya, repositori ini melayani dasar dari perangkat instalasi software seperti
Installshield (untuk sistem Windows) atau AIX Systems Management Interface Tool (SMIT).
Selain itu hal tersebut dapat dianggap sebagai dasar pengetahuan yang mengandung informasi
penting dengan memperhatikan kesesuaian dari layanan dan aplikasi. Fakta bahwa sebuah paket
software tertentu harus sudah disajikan pada sistem sehingga paket lainnya dapat diinstal dengan
sukses, secara tidak langsung layanan yang diimplementasikan oleh paket yang terakhir
bergantung pada layanan yang diimplementasikan oleh yang sebelumnya. Dengan kata lain, jika
paket software tertentu memiliki daftar paket software lain sebagai prasyarat instalasi, kita dapat
menarik kesimpulan bahwa hubungan ketergantungan ini juga valid untuk hal lainnya, sebagai
contoh adalah layanan dan aplikasi.
Sebuah contoh sederhana akan disajikan untuk mengilustrasikan hal ini : jika repositori
sistem mengindikasikan bahwa sebuah Web server tertentu memiliki sebuah implementasi
TCP/IP tertentu sebagai prasyarat, hal yang sangat utama ini dapat berarti bahwa :
1. Fungsional, sebagai contoh, model implementasi relasi independen untuk kategori layanan
WWW dan TCP/IP dapat dibentuk. Model tersebut menggambarkan layanan dalam istilah
fungsionalitas yang disediakan dan pada layanan lain mana hal tersebut bergantung. Fakta bahwa
layanan WWW bergantung (diantara lainnya) pada ketersediaan dari layanan TCP/IP secara
tidak langsung sebuah hubungan ketergantungan fungsional antara layanan WWW danTCP/IP
didefinisikan dan dikuatkan oleh rutinitas instalasi.
2. Struktural, sebagai contoh, manajemen informasi spesifik dan bergantung implementasi yang
tersedia. Sebuah algoritma yang cocok untuk penelitian permasalahan otomatis untuk kesalahan
fungsi layanan WWW harus mengecek apakah kondisi operasional dari Web server yang spesifik
dan yang mendasari TCP/IP stack adalah up. Hal ini memungkinkan karena hubungan
ketergantungan dari sebuah layanan tertentu didaftarkan secara eksplisit pada repositori sistem.
Bagian 4.2 akan memberikan contoh struktur data tersebut.
Menemukan dan mendaftarkan hubungan ketergantungan yang dimiliki aplikasi pada layanan
lapisan di bawahnya dalam lingkungan jaringan merupakan masalah yang sulit. Hal tersebut
memiliki aspek baik statis maupun diamis, yaitu, ketergantungan diidentifikasi pada saat
menginstal aplikasi dan ditemukan pada saat runtime. Model ketergantungan fungsional dapat
digunakan untuk menggambarkan ketergantungan statis antara kategori aplikasi dan layanan.
Bagian structural menangkap informasi dinamis yang terkait dengan implementasi layanan
konkrit. Pada bagian berikutnya, kita akan mengilustrasikan pendekatan dengan menggunakan
contoh.
4.2 Ketergantungan Dalam Sistem :IBM AIX Object Data Manager
Object Data Manager (ODM) merupakan repositori dari sistem operasi AIX dan mengandung
informasi mengenai komponen sistem operasi yang berbeda seperti device driver, layanan
jaringan, dan antarmuka grafikal, middleware (seperti object request broker, sistem antrian
pesan), perangkat pengembangan (compiler, debugger, CASE-tool) dan komponen tambahan
seperti basis data dan Web server. Selanjutnya, aplikasi seperti Web browser, database client,
management platform, groupware system juga disimpan ke dalam repositori.
ODM memperoleh pengetahuan mengenai komponen yang baru dari software saat waktu
instalasi dari installp software installation routine yang dipanggil oleh SMIT. Rutinitas ini
membaca template deskripsi software (sebuah contoh dari template sederhana ini yang biasa bagi
semua aplikasi yang digambarkan di bawah) yang muncul dengan paket software baru,
memeriksa prasyarat dan setelah berhasil menyelesaikan tes prasyarat menginstal software
dan memasuki template deskripsi ke ODM. Diingat bahwa informasi yang ada pada template
dapat ditambahkan setelah aplikasi telah di-compile . Jadi hal tersebut tidak harus disediakan
oleh pengembang aplikasi (walaupun hal ini diinginkan) tapi dapat ditambahkan oleh system
administrator atau third party.
Sekarang kita akan melihat bagaimana informasi konfigurasi untuk paket software
direpresentasikan pada ODM. Entri berikut ini untuk komponen* (bos.net.tcp.server) yang
berhasil (state=5) diinstal menjadi bagian dari paket jaringan sistem operasi (bos.net) dari IBM
AIX mengindikasikan bahwa software ini (versi 4.2.1.0) menggantikan dan mengubah nama
komponen bosnet.tcpip.obj versi 4.1.0.0 yang sebelumnya diinstal.
lpp_name = bos.net.tcp.server /* component name */
comp_id = /* component identifier */
update = 0 /* update (yes/no) */
name = bos.net /* package name */
state = 5 /* committed/applied/rejected */
ver = 4 /* component version# */
rel = 2 /* component release# */
mod = 1 /* component modification# */
fix = 0 /* fix (yes/no) */
ptf = /* fix id */
media = 3 /* install media type */
sceded_by = /* superseded by */
fixinfo = /* verbose fix description */
prereq = prereq bos.rte 4.2.0.0, *prereq bos.net.tcp.client 4.1.0.0
description = TCP/IP Server
supersedes = bosnet.tcpip.obj 4.1.0.0

Informasi tambahan untuk perbaikan/patch tambahan dan deskripsinya juga dapat
ditemukan dalam template ini. Satu bagian penting yang khusus dari struktur data ini adalah entri
prereq (prerequisites) karena menunjukkan dimana paket software lainnya harus sudah
disiapkan di sistem sehingga komponen ini dapat diinstal dengan sukses. Pada bagian berikutnya,
kita akan menunjukkan bagaimana kita menggunakan informasi ini untuk kepentingan kita.
Sejak setiap paket software yang diinstal pada AIX harus membuat daftar properti pada format
yang dapat dibaca oleh mesin, selanjutnya kita dapat mengasumsikan bahwa ketergantungan
menutupi sebuah set paket software yang luas. ODM dapat diakses dengan tiga cara berbeda :
1. Mekanisme yang paling umum untuk administrator sistem untuk berinteraksi dengan
ODM adalah SMIT, sebuah antarmuka grafikal yang menyediakan menu-menu untuk
tugas-tugas umum system administrator seperti, menginstal dan mengkonfigurasi
komponen sistem dan aplikasi.
2. Selain itu, terdapat antarmuka command line yang digunakan untuk mengakses data
ODM dari shell atau Perl script. Entri ODM dapat dicari berdasarkan criteria berbeda dan
didapatkan kembali (odmget command), dimodifikasi (odmchange), ditambah (odmadd)
atau dihapus (odmdelete). Struktur data ODM dapat ditampilkan menggunakan
odmshow.
3. Cara yang paling rumit menjalankan berbagai operasi terhadap ODM adalah melalui C-
API yang berisi 22 subrutin yang mencakup berbagai fungsi query dan adminstratif.

Gambar 2 : Model ketergantungan layanan fungsional secara otomatis
Dengan menggunakan operasi query pada ODM API, merupakan hal yang mungkin untuk
mendapatkan baik model ketergantungan layanan fungsional maupun structural pada saat
runtime. Gambar 2 menunjukkan sebuah kutipan dari model ketergantungan layanan fungsional
(termasuk aplikasi seperti DB2 Database Clients, layanan seperti NFS dan DNS) pada sebuah
sistem yang berjalan dan bukan merupakan model yang abstrak. Hal ini dibentuk dengan
mengevaluasi kolom description dan prereq pada template di atas. Model ketergantungan
structural lebih mendetail dan menghilangkan seluruh singkatan; mengandung informasi pada
komponen berbeda yang menyusun sebuah layanan dan berdasarkan pada entri lpp_name, ver,
dan rel sebagai tambahan untuk semua kolom yang dikutip di atas.
Analisis ini menunjukkan bahwa repositori sistem seperti ODM menampilkan sumber
yang kaya akan informasi manajemen aplikasi, tidak hanya memberi konfigurasi dari aplikasi
yang telah diinstal tapi juga untuk meneliti hubungan ketergantungan antara aplikasi dan
layanan. Sebagai catatan bahwa jumlah informasi yang banyak ini telah didapatkan tanpa adanya
perangkat tertentu dari komponen. Satu-satunya persyaratan adalah komponen aplikasi dapat
dideskripsikan menggunakan template di atas. Namun dapat ditambahkan sebagai catatan bahwa
:
1. Repositori sistem mengacu hanya pada sistem individual dan dengan demikian, untuk
sebagian besar bagian, intra-sistem dependensi. Sejak manajemen end-to-end terutama
berkaitan dengan ketergantungan antar sistem, kita harus mengembangkan mekanisme
yang memungkinkan kita untuk membentuk ketergantungan antara komponen client dan
server yang ditempatkan, secara umum, pada sistem yang berbeda. Topik ini dialamatkan
pada bagian berikutnya.
2. Merupakan hal yang penting untuk menghubungkan informasi statis yang berada pada
repositori dengan informasi dinamis yang didapatkan dari proses pada saat runtime
(sebagai contoh, keadaan serta prioritasnya, persentase penggunaan CPU cycle dan
memori, userID dari pemiliknya, dll). Persyaratan yang wajib untuk hal ini adalah
template juga berisi nama proses dari komponennya (dimana bukan merupakan
permasalahan pada implementasi ODM saat ini). Namun, karena nama proses telah
diketahui saat instalasi, hal tersebut dapat dengan mudah dimasukkan ke dalam ODM
dengan menambahkan sebuah tambahan process name ke struktur data.
4.3 ketergantungan Antar Sistem
Seperti yang telah disebutkan pada bagian 3, merupakan hal yang penting untuk permasalahan
penelitian end-to-end bahwa informasi mengenai ketergantungan antar sistem ada, karena
penting untuk mengetahui apakah bagian client dan server dari layanan yang diberikan dapat
berjalan dengan baik. Pertama kita akan memeriksa kemungkinan dari menentukan
permasalahan pada sisi client dan kemudian menggambarkan mekanisme apa yang tersedia
untuk server.
Sangat sering informasi mengenai server yang akan dikoneksikan dengan client telah
didaftarkan secara eksplisit pada file konfigurasi client : sebuah DNS resolver tidak hanya
memiliki informasi mengenai nama domain-nya tetapi juga nama dari server-nya. Beberapa
tandingan untuk hal ini adalah layanan WWW dan FTP, dimana nama server tidak dapat
diketahui dengan jelas. Namun, masalah ini diringankan dengan fakta bahwa biasanya proxy
server telah diketahui, maka memungkinkan untuk menentukan apakah merupakan permasalahan
lokal untuk client atau berada pada proxy.
Pada sisi server, kita dapat juga menggunakan daftar ketergantungan pada ODM untuk
menentukan ketergantungan antar sistem untuk alas an berikut:
y Client dan server biasanya berbagi ketergantungan fungsional yang sama (sebagai
contoh, baik web client dan web server bergantung pada ketersediaan layanan DNS
dimana pada saatnya bergantung pada layanan IP yang bekerja). Model
ketergantungan layanan fungsional pada Gambar 2 berlaku untuk client dan server.
y Dari sudut pandang instalasi, melihat struktur ketergantungan yang disimpan pada ODM,
client yang diberikan layanan merupakan prasyarat bagi rekanan servernya. Hal ini
berarti perangkat lunak server hanya dapat diinstal juka bagian client telah ada pada
sistem; template ODM untuk TCP/IP server dideskripsikan pada bagian 4.2 telah
dinyatakan dengan jelas pada argument kedua dari atribut prereq.Selanjutnya kita dapat
mengasumsikan bahwa client harus menguji bahwa server telah diinstal secara lokal serta
memfasilitasi pengujian dari server karena tidak ada jaringan atau sistem lanjutan yang
dilibatkan.

Walaupun kita telah melihat bahwa repositori sistem menyediakan jumlah informasi
bermanfaat yang dapat diterima untuk manajemen aplikasi, kita harus menunjukkan
bahwa satu jenis ketergantungan tertentu tidak dapat dijalani: hal ini belum
memungkinkan untuk menentukan apakah paket software diinstal pada sistem file lokal
ataupun remote. Ketergantungan tambahan dikenalkan oleh networked file system (serta
sistem operasi yang digunakannya) tidak muncul pada model. Algoritma menentukan
masalah yang cocok harus diverifikasi apakah jalur instalasi (terdapat pada repositori)
mengacu pada local atau remote system (dengan memeriksa misalnya, konfigurasi NFS)
dan menurut model terbaru.
Permasalahan lainadalah bahwa informasi yang diidentifikasikan pada bagian ini
relevan terhadap manajemen konfigurasi dan fault tetapi tidak sesuai untuk manajemen
performa dan akuntansi: merupakan hal yang mungkin untuk memverifikasi apakah
layanan dan prasyaratnya dan rekannya dapat bekerja tapi kita tidak dapat memastikan
apakah layanan menampilkan tugasnya dalam periode waktu yang dapat diterima.
Dengan tujuan untuk memuaskan kinerja yang berhubungan dengan SLA, aplikasi harus
dilengkapi perangkat dengan cocok. Tivoli Application Response Management (ARM)
API dengan ekstensi terakhirnya merupakan langkah pertama pada arah ini.


Gambar 3 : Komponen dari Arsitektur Manajemen Layanan Aplikasi
5. Sebuah Arsitektur untuk Manajemen Layanan Aplikasi
Seperti yang telah disebutkan pada bagian 1, persyaratan utama merupakan pendekatan untuk
mengatur layanan aplikasi yang dibutuhkan untuk mengalamatkan fakta bahwa NSP telah
membuat investasi yang signifikan pada sistem manajemen jaringan. Arsitek keseluruhan kita
dikutip dalam Gambar 3 : platform manajemen jaringan off-the-shelf menyediakan dasar dari
arsitektur ini dan menawarkan layanan seperti penerima dan pengirim event , fungsi penjelajah
sumber daya atau layanan topologi.
5.1 Analisis Ketergantungan Aplikasi
Sebagai hasil dari analisis statis selama instalasi dan provisioning aplikasi, setiap aplikasi
menawarkan layanan yang telah dikaitkan sebuah daftar resource dalam layer manajemen
jaringan yang menyediakan dasar untuk layanan tersebut. Data ini disimpan pada sebuah
database yang dibentuk dan dikelola oleh tahap analisis ketergantungan aplikasi yang telah
dibahas pada bagian sebelumnya dan dikutip pada sebelah kanan atas dari Gambar 3. Dalam
kasus content hosting scenario yang didiskusikan pada bagian 3 (dan ditunjukkan pada Gambar
1), daftar sumber daya dihubungkan dengan aplikasi ini berisi sumber daya yang mendukung
konektivitas IP, back-end database , NFS, dan DNS
5.2 Komponen dari Arsitektur
Application Service Agent
Application service agent merupakan titik fokus untuk mengelola penawaran layanan individual.
Dari implementasi sudut pandang, sama dengan aplikasi yang beroperasi di atas platform
manajemen jaringan. Jika, misalnya, NSP memiliki tiga penawaran layanan yang berbeda (DNS,
web-based content hosting, dan shared firewall) desain kita menghasilkan tiga agen manajemen
layanan, masing-masing bertanggung jawab untuk satu penawaran. Agen menerima peringatan
tentang kejadian dari MLM melalui platform API dan memperbarui tampilan dari layanan yang
dikelola. Tampilan ini paling baik direpresentasikan dengan multi-level resource tree, dimana
elemen-elemen pada satu tingkat bergantung pada ketersediaan dan status dari elemen pada
tingkat yang lebih rendah berikutnya. Satu cara untuk menggunakan tampilan layanan adalah
dengan menampilkannya secara grafik pada salah satu pusat manajemen layanan dimana seorang
manajer layanan bisa mengamati status dari layanan dan melakukan penelusuran secara khusus
untuk penyelesaian masalah.
Ketergantungan fungsional menghasilkan model layanan yang umum dimana bagian
struktural menyediakan informasi detail pada komponen yang terlibat. Di saat model fungsional
disimpan pada MLM dan pada platform manajemen, agen layanan aplikasi mengelola tampilan
struktural untuk setiap pelanggan secara individu. Hal ini mengarah pada tingkat distribusi yang
tinggi dan merupakan alasan utama untuk skalabilitas dari pendekatan kita. Selama inisialisasi,
sebuah agen layanan mendapatkan file konfigurasi yang dijalankan pada fase analisis
ketergantungan aplikasi, yang digunakan untuk membentuk model struktural.
Resource Broker
Fungsi dari resource broker adalah untuk melayani sebagai akses utama ke Resource Directory.
Entitas yang berinteraksi dengan Resource Broker adalah agen layanan aplikasi dan MLM:
sebuah agen layanan aplikasi mengirim daftar sumber daya yang terdapat pada tampilan layanan
untuk Broker. MLM berkomunikasi dengan Resourcer Broker untuk menyimpan sumber daya ke
dalam domain mereka dan untuk memperbarui catatan ini secara periodik. Kemudian Resource
Broker dapat membentuk asosiasi antara sebuah Application Service Agent dan satu set MLM,
sehingga memungkinkan untuk menentukan status dari sumber daya yang dibutuhkan oleh
layanan aplikasi. MLM menggunakan catatan dari Resource Broker untuk memancarkan
kejadian yang terkait dengan sumber daya yang berada di bawah control kepada Application
Service Agent atau kepada management platform, masing-masing.
Resource Directory
Fungsi utama dari Resource Directory adalah untuk mengelola sebuah catatan mengenai semua
sumber daya yang dimonitor oleh MLM tertentu. Resource Directory merespon query dan dan
menjalankan operasi update yang didapatkan dari Resource Broker dan menyediakan tempat
penyimpanan untuk catatan tersebut. Bagian berikutnya akan mendeskripsikan alur informasi
yang mengambil tempat dengan tujuan untuk memproduksi tampilan status dari penawaran
layanan aplikasi.
5.3 Alur Informasi Manajemen Layanan
Gambar 4 mengutip alur informasi setiap agen layanan menginisialisasi dirinya dan menjadi siap
untuk menerima status terbaru yang berhubungan dengan sumber daya yang medukung layanan
yang dimonitor oleh agen tersebut. Alur pada umumnya seperti berikut :
Sebuah agen layanan aplikasi bertugas untuk mengirimkan sebuah request ke Resource
Broker untuk menentukan status dari sumber daya dimana layanan bergantung. Ia menyediakan
resource Broker sebuah daftar, RLa, yang berisi resource identifier dari semua sumber daya
dimana layanan ini bergantung. Daftar ini dijalankan selama fase analisis ketergantungan
aplikasi.
Resource Broker membuat pertanyaan pada directory dengan menggunakan RLa dan
mendapatkan sebuah daftar {(MLM
1
,RLm
1
),,(MLM
i
,RLm
i
)} dari semua MLM yang
bertanggung jawab untuk memonitor sekelompok sumber daya yang didenotasikan oleh RLa.
Pasangan (MLM
i
,RLm
i
) merupakan pasangan sumber daya RLm
i
yang dimonitor oleh MLM ke
i.

Gambar 4 : Alur Informasi antara Komponen Manajemen
Dengan mendapatkan daftar di atas, Resource Broker menghubungi setiap MLM yang
relevan dengan mengirim Application Service Agent ID dan daftar sumber daya yang
berhubungan RLm
i
ke MLM ke-i. Pada poin ini, MLM I mengetahui ke Application Service
Agent mana kejadian berhubungan ke sumber daya pada RLm
i
harus dikirim.
Untuk alasan efisiensi, kejadian dari MLM disaring oleh layanan event dari platform
manajemen. Bergantung pada ID agen yang dikirimkan ke event, dimana pada saatnya,
menggunakan informasi pada event untuk memperbarui informasi status pada tampilan layanan.
6. Kesimpulan dan Pandangan
Pada makalah ini kita telah mendeskripsikan kerangka kerja manajemen layanan aplikasi yang
bergantung pada platform manajemen jaringan off-the-shelf. Tugas itu didorong oleh solusi yang
disampaikan untuk IBM Global Network, sebuah contoh dari penyedia layanan jaringan (NSP)
yang telah berkembang untuk menyediakan pengelolaan layanan aplikasi end-to-end sebagai
fungsi nilai tambah pada layanan konektivitas IP dasar. Sebuah kunci persyaratan untuk
manajemen layanan aplikasi , yang disorot pada makalah ini, merupakan identifikasi,
pendaftaran, dan representasi dari ketergantungan informasi, sebagai contoh, ketergantungan
bahwa sebuah sumber daya pada layer yang ada di bawahnya yang dimiliki elemen pada layer
aplikasi seperti middleware dan jaringan. Pendekatan yang digunakan pada makalah ini adalah
pragmatik dan berdasarkan pada analisis ketergantungan statis yang menghasilkan informasi
pada entitas di dalam sebuah sistem (intra-sistem) dan antara pasangan entitas dari layanan
(inter-sistem). Kita menunjukkan bahwa sistem operasi standar, seperti Windows NT, AIX, dan
Linux, kaya akan informasi pada repositorinya yang dapat dimanfaatkan untuk automated
generation of dependencies (generasi otomatis dari kertergantungan). Pendekatan kita memiliki
kelebihan tambahan bahwa tidak memberikan beban pada pengembang aplikasi untuk member
pelengkap pada aplikasinya.

Identifikasi dari ketergantungan merupakan sebuah prasyarat untuk penyebaran dari
layanan penyelesai masalah yang menangkap pengetahuan manajemen kesalahan (fault
management) yang terdapat pada sistem dokumentasi kesalahan NSP. Memunculkan teknologi
untuk membangun repositori generasi berikutnya seperti Jini dan Lightweight Directory Access
Protocol (LDAP) memfasilitasi akses dan perubahan dinamis dari informasi manajemen.
Daftar Pustaka
1997. Application Management Specification.Tivoli Systems.