Ahmed Mihoob,
Carlos Molina-Jimenez and Santosh Shrivastava*
Abstrak
"Bayar hanya untuk apa yang Anda
gunakan" prinsip mendasari kebijakan pengisian layanan cloud yang
digunakan secara luas yang ada di o ff er. Idealnya untuk layanan ini, konsumen
harus berada dalam posisi untuk memverifikasi tuduhan ditagih kepada mereka. Namun,
tidak seperti layanan utilitas tradisional seperti gas dan listrik, tidak ada
layanan metering konsumen terpercaya yang tersedia untuk layanan cloud,
sehingga konsumen tidak punya pilihan selain bergantung pada data penggunaan
yang disediakan oleh penyedia. Dalam terang ini, kertas mengusulkan gagasan
Sumber Daya Akuntansi Model Konsumen-sentris untuk sumber daya cloud. Model
akuntansi sangat consumer-centric jika semua data yang membutuhkan model untuk
menghitung biaya penagihan dapat dikumpulkan secara independen oleh konsumen
(atau pihak ketiga yang terpercaya, TTP); dalam efek, ini berarti bahwa
konsumen (atau TTP) harus berada dalam posisi untuk menjalankan layanan
pengukuran sendiri. Dengan pandangan ini dalam pikiran, model akuntansi beberapa
layanan cloud banyak digunakan diperiksa dan sumber-sumber kesulitan-di FFI
dalam pengumpulan data yang diidentifikasi, termasuk penyebab yang dapat
menyebabkan perbedaan antara data metering yang dikumpulkan oleh konsumen dan
penyedia. Makalah ini melanjutkan dengan menunjukkan bagaimana penyedia layanan
awan dapat meningkatkan model akuntansi mereka untuk membuat mereka
konsumen-sentris.
Kata kunci: Cloud konsumsi sumber daya, sumber
daya penyimpanan, sumber daya komputasi, Sumber Daya metering, model Akuntansi,
layanan web Amazon
1.
Perkenalan
Layanan komputasi awan tersedia untuk konsumen
mulai dari penyediaan sumber daya dasar komputasi seperti penyimpanan dan
menghitung daya (infrastruktur sebagai wakil ser, IaaS) untuk layanan aplikasi
enterprise yang canggih (software sebagai layanan, SaaS). Sebuah model bisnis
umum adalah untuk mengisi konsumen secara bayar per-digunakan di mana mereka
secara berkala membayar untuk sumber daya yang mereka miliki dikonsumsi. Tak
perlu dikatakan bahwa untuk setiap ser wakil bayar per-digunakan, konsumen
harus disediakan dengan model akuntansi sumber daya jelas bahwa justru
menggambarkan semua sumber daya konstituen dikenakan biaya layanan dan
bagaimana biaya penagihan dihitung dari penggunaan sumber daya (konsumsi sumber
daya) Data yang dikumpulkan atas nama konsumen selama periode waktu tertentu.
Jika konsumen memiliki akses ke data penggunaan sumber daya tersebut maka
mereka dapat menggunakannya dengan berbagai cara yang menarik, seperti, membuat
mereka penagihan applications sadar, IT perencanaan anggaran, menciptakan
layanan percaloan yang mengotomatisasi pemilihan jasa sejalan
* Korespondensi: santosh.shrivastava@ncl.ac.uk
School of Computing Science, Newcastle University,
Newcastle upon Tyne,
NE1 7RU, UK
dengan kebutuhan pengguna dan sebagainya.
Memang, dalam est antar penyedia layanan untuk membuat data konsumsi sumber
daya yang tersedia untuk konsumen; kebetulan semua penyedia yang kami ketahui
lakukan membuat data tersebut dapat diakses oleh konsumen mereka secara tepat
waktu.
Sebuah isu yang diangkat adalah akuntabilitas
sumber daya data penggunaan: yang melakukan pengukuran untuk mengumpulkan data
penggunaan sumber daya - provider, Sumeria con, pihak ketiga terpercaya (TTP),
atau beberapa kombinasi dari thema? Akuntabilitas penyedia sisi adalah norma
untuk layanan utilitas tradisional seperti air, gas dan listrik, di mana
penyedia menggunakan perangkat metering (dipercaya oleh konsumen) yang
ditempatkan di tempat yang kepada konsumen. Saat ini, akuntabilitas penyedia
sisi juga merupakan dasar bagi penyedia layanan cloud, meskipun, belum ada
fasilitas setara dengan metering konsumen dipercaya; lebih, konsumen tidak
punya pilihan selain untuk mengambil penggunaan apapun data yang disediakan
oleh penyedia setia.
Mengingat pembahasan di atas, kami mengusulkan
gagasan tentang Sumber Daya Akuntansi Model Konsumen-sentris untuk sumber daya
cloud. Kami mengatakan bahwa model akuntansi lemah konsumen-sentris jika semua
data yang membutuhkan model untuk menghitung biaya penagihan dapat dilihat
pemrograman dari provider. Selanjutnya, kita mengatakan bahwa model akuntansi
sangat consumer-centric jika semua data yang membutuhkan model untuk menghitung
biaya penagihan dapat dikumpulkan secara independen oleh konsumen (atau TTP a);
dalam e ff ect, ini berarti bahwa konsumen (atau TTP a) harus berada dalam
posisi untuk menjalankan layanan pengukuran sendiri. Kami berpendapat bahwa
dalam kepentingan penyedia untuk membuat model akuntansi jasa mereka setidaknya
lemah konsumen-sentris. Sangat model sentris konsumen-harus membuktikan lebih
menarik bagi konsumen karena mereka memungkinkan konsumen untuk menggabungkan
yang bebas yang konsistensi independen atau kewajaran cek serta alarm
meningkatkan ketika perbedaan jelas dicurigai konsumsi angka-angka;
Selanjutnya, skema pengisian inovatif dapat dibangun oleh konsumen yang diri
mereka-o ff kenai layanan pihak ketiga. Sangat model akuntansi sentris
konsumen-memiliki sifat yang diinginkan keterbukaan dan transparansi, karena
pengguna jasa berada dalam posisi untuk memverifikasi tuduhan ditagih kepada
mereka.
Sebagai contoh memotivasi, mempertimbangkan
konsumen yang menyewa layanan penyimpanan untuk menjalankan sebuah aplikasi
yang ditunjukkan pada Gambar 1. Penyimpanan dikonsumsi oleh aplikasi konsumen
dan oleh host aplikasi oleh pengguna lain (user1, user2, dll) yang mengakses
layanan penyimpanan dengan biaya konsumen. Contoh dari kasus ini adalah
konsumen dalam menggunakan layanan penyimpanan untuk menyediakan foto atau
video sharing layanan kepada pengguna lain. Skenario ideal adalah bahwa
konsumen dapat instrumen aplikasi untuk kumpulkan semua data konsumsi storage
yang diperlukan dan menggunakan model akuntansi penyedia untuk secara akurat
mengestimasi kawin biaya, dan menggunakan informasi tersebut untuk memberikan
layanan dengan harga kompetitif kepada pengguna .
Karena penyedia layanan cloud lakukan
mempublikasikan informasi mereka mendorong pembayaran ing, perlu menyelidiki
apakah informasi mereka sesuai dengan gagasan yang diusulkan model ing
pertanggungjawaban yang konsumen-sentris. Dengan pandangan ini dalam pikiran,
kita mempelajari model akuntansi berbagai penyedia terlayaninya dua jenis
sumber daya dasar, penyimpanan dan prosesor. Kami menyimpulkan bahwa model
penyedia ing-pemimpin, Amazon Web Services, dapat diambil sebagai kelas yang
representatif. Oleh karena itu kami berkonsentrasi paling atas model mereka.
Kami melakukan evaluasi rinci dari model akuntansi dua layanan infrastruktur
cloud dari Amazon (Simple Storage Service, S3, dan Elastic Compute Cloud, EC2)
dan Cloud Storage Jaringan (CSN) dari Nirvanix, sebuah layanan yang mirip
dengan S3.
Kami mulai dengan independen mengumpulkan
(dengan pemeriksaan permintaan dan tanggapan) sendiri penggunaan sumber daya
(con sangkaan) data kami untuk S3 dan membandingkannya dengan data penyedia.
Penyelidikan kami menunjukkan bahwa meskipun secara konseptual layanan yang
sangat sederhana, deskripsi model akuntansi S3 tetap su ff ers dari ambiguitas
dan ketidaklengkapan dengan hasil bahwa data penggunaan sumber daya yang model
yang diperlukan untuk menghitung biaya penagihan yang dikumpulkan oleh konsumen
dapat berubah menjadi berlainan dari yang dikumpulkan oleh Amazon. Evaluasi
serupa Nirvanix CSN dan EC2 juga mengungkapkan beberapa kekurangan. Penyedia
layanan dapat belajar dari studi evaluasi kami
memeriksa kembali model akuntansi mereka.
Secara khusus, kami merekomendasikan bahwa penyedia awan harus melalui latihan
membangun sumber daya layanan akuntansi pihak ketiga, dan berdasarkan latihan
yang, lakukan KASIH amendemen model sehingga untuk menghilangkan potensi sumber
ambiguitas dan ketidaklengkapan dalam deskripsi model, sehingga sejauh mungkin,
konsumen dapat kumpulkan dengan kemudahan penggunaan data mereka sendiri yang
cocok dengan sisi Data provider dengan su FFI efisien precisionb.
Makalah ini melaporkan hasil kerja kami dan
membuat kontribusi sebagai berikut:
- Menyajikan cara sistematis menggambarkan
model akuntansi sumber daya sehingga mereka dapat dipahami dan beralasan
tentang oleh konsumen;
- Itu justru identifikasi fi es penyebab yang
dapat menyebabkan perbedaan antara data penggunaan sumber daya yang dikumpulkan
oleh penyedia dan konsumen, dan apakah perbedaan dapat diselesaikan; dan
- Menyajikan ide-ide tentang bagaimana model
akuntansi harus dibangun sehingga membuat konsumen-sentris.
Kita mulai dengan menghadirkan pekerjaan yang
berhubungan di daerah ini; bagian berikut (Bagian 3) menyajikan informasi latar
belakang yang relevan pada akuntansi sumber daya. Bagian 4 menyajikan cara
sistematis menggambarkan sumber daya pertanggungjawaban ing model. Bagian 5
sampai tujuh memeriksa masing-masing mengidentifikasi penyebab yang dapat
menyebabkan perbedaan antara konsumsi sumber daya angka-angka independen
dikumpulkan oleh penyedia dan konsumen. Belajar dari latihan ini, Bagian 8
menyajikan jalan ke depan: bagaimana seharusnya sumber daya model akuntansi
dibuat konsumen-sentris. 9 menggambarkan bagaimana model konsumen-sentris dapat
membentuk dasar untuk menciptakan alat untuk konsumen yang mengotomatisas tugas
komputasi biaya penagihan. Penutup disajikan dalam Bagian 10.
2 pekerjaan terkait
Arsitektur untuk akuntansi dan penagihan di
keburukan awan-jasa terdiri dari dua atau lebih membangun struktur infrastruc-
federasi (misalnya, penyimpanan dan penyedia komputasi) dibahas dalam [1].
Arsitektur mengasumsikan tence exis- model akuntansi didefinisikan dengan baik
de yang digunakan untuk sumber daya akuntansi dikonsumsi oleh pengguna akhir
dan sumber daya akuntansi yang penyedia awan mengkonsumsi dari infrastruktur
menulis. Masalah ini terkait dengan skenario yang kami sajikan pada Gambar 1. Dalam
[2], penulis membahas persyaratan untuk jasa akuntansi dan penagihan, tetapi
dalam konteks jaringan federasi penyedia telekomunikasi. Sebuah diskusi rinci
sistem akuntansi yang ditujukan untuk kejahatan telekomunikasi ser juga
disediakan dalam [3]. Makalah ini mengabaikan kebutuhan untuk menyediakan
konsumen dengan cara melakukan akuntansi konsumen-side.
Dalam [4], penulis mengamati bahwa "kotak
hitam dan sifat dinamis dari infrastruktur cloud" membuat-beda fi kultus
bagi konsumen untuk "alasan tentang biaya yang aplikasi mereka
dikenakan". Para penulis membuat kasus untuk kerangka kerja untuk veri fi
mampu sumber daya akuntansi sehingga konsumen bisa mendapatkan jaminan sekitar
dua pertanyaan: (i) aku mengkonsumsi apa yang saya dikenakan? dan (ii) harus saya
telah dikonsumsi apa yang saya dikenakan? Veri kemampuan fi jelas berkaitan
erat dengan pengertian akuntansi sumber daya konsumen-sentris yang dikembangkan
dalam tulisan ini.
Konsep kami akuntansi sumber daya
konsumen-sentris memiliki semangat yang sama bahwa monitorability perjanjian
tingkat layanan, dibahas dalam [5]; dalam pekerjaan ini, penulis menunjukkan
bahwa perjanjian tingkat layanan yang ditandatangani antara klien dan penyedia
harus tepat dan hanya mencakup peristiwa yang terlihat dengan klien dan pihak
lain yang berkepentingan.
Dalam [6], penulis mengembangkan model di mana
konsumen dan penyedia independen mengukur konsumsi sumber daya, membandingkan
hasil mereka dan menyepakati hasil yang saling dipercaya. Makalah ini membahas
isu-isu te-teknik yang hal ini melibatkan, termasuk koleksi sisi konsumen data
metering, divergensi potensial antara dua tagihan independen dihitung,
penyelesaian sengketa dan berbagi yang tidak dapat ditipu catatan penggunaan
sumber daya. Tentu, titik awal untuk sistem tersebut akan menjadi model
akuntansi konsumen-sentris sumber daya cloud.
Pemahaman yang baik tentang sumber daya awan
akuntansi els-model sangat penting untuk konsumen yang tertarik dalam
perencanaan untuk meminimalkan pengeluaran sumber daya cloud. Pertanyaan yang
diajukan adalah apa beban kerja outsourcing, yang provider, sumber daya apa
yang harus menyewa, kapan, dan sebagainya. Contoh-contoh hasil penelitian ke
arah ini dilaporkan dalam
[7-9]. Dalam [8], penulis membahas bagaimana
layanan akuntansi dikerahkan dalam suatu organisasi dapat digunakan untuk
mengontrol pengeluaran sumber daya publik awan; layanan akuntansi mereka
bergantung pada data yang diunduh dari penyedia cloud bukan menghitung secara
lokal. Dalam [10], penulis mengambil Amazon awan sebagai contoh penyedia awan
dan estimasi kawin kinerja dan biaya moneter untuk menghitung data-intensif
(terabyte) bekerja aliran yang membutuhkan jam waktu CPU. Penelitian ini
analisis (bukan eksperimen mental) dan berdasarkan model akuntansi penulis. Sebagai
contoh, untuk menghasilkan yang sebenarnya CPU-jam, mereka mengabaikan rincian
dari Amazon misalnya jam dan menganggap CPU detik perhitungan. Karya ini
menekankan relevansi model akuntansi. Kesesuaian Amazon S3, EC2 dan SQS jasa
sebagai platform untuk data intensif ilmiah aplikasi c dipelajari dalam [11];
Penelitian ini berfokus pada performanceperformance sports (misalnya, jumlah
operasi per detik), ketersediaan dan biaya. Hal ini menunjukkan bahwa biaya
dapat dikurangi dengan membangun aplikasi biaya-sadar yang mengeksploitasi pola
penggunaan data; misalnya, dengan mendukung data yang derivasi dari data mentah
terhadap penyimpanan data diproses. Argumen ini mendukung bagi relevansi
praktis dan komersial penelitian kami model akuntansi sumber daya.
3 Latar Belakang
Akuntansi sumber daya itu perlu untuk
menentukan jumlah sumber daya yang dikonsumsi oleh konsumen yang diberikan
(juga disebut klien dan konsumen) selama interval waktu tertentu, misalnya,
jangka waktu penagihan. Sistem akuntansi com- ditimbulkan dari tiga layanan
dasar: metering, akuntansi dan penagihan.
Kami menunjukkan sistem akuntansi sisi konsumen
khas pada Gambar 2. Kami berasumsi bahwa sumber daya yang terkena sebagai
jasa-jasa melalui satu atau lebih antarmuka layanan. Seperti ditunjukkan dalam
Figur, layanan metering penyadapan pesan tra FFI c antara aplikasi konsumen dan
layanan awan dan ekstrak data yang relevan yang diperlukan untuk penggunaan
sumber daya ing Calculat- (misalnya, ukuran pesan yang akan diperlukan untuk
menghitung penggunaan bandwidth). Layanan metering menyimpan data yang
dikumpulkan untuk digunakan oleh layanan akuntansi. Layanan akuntansi mengambil
data metering, menghitung konsumsi sumber daya dari data menggunakan model
akuntansi dan menghasilkan data akuntansi yang dibutuhkan oleh layanan
penagihan untuk menghitung data penagihan.
Model akuntansi adalah penyedia-spesifik dalam
arti bahwa fungsi model akuntansi ditentukan dengan kebijakan penyedia.
Kebijakan ini menentukan bagaimana metrik yang dihasilkan oleh layanan metering
nya harus ditafsirkan; misalnya, 1,7 GB penyimpanan menyebabkan konsumsi
rokoknya dapat diinterpretasikan oleh model akuntansi penyedia baik sebagai 1
atau 2 GB. Model akuntansi penyedia awan biasanya tersedia dari halaman web
mereka dan pada prinsipnya dapat digunakan oleh konsumen untuk melakukan akuntansi
sumber daya mereka sendiri. The di FFI culty sini untuk konsumen adalah untuk
mengekstrak model akuntansi dari dokumentasi online mereka karena kebanyakan
penyedia yang kami ketahui, tidak perlu mengaburkan model akuntansi mereka
dengan metering dan penagihan parameter. Penjelasan terstruktur menggunakan
model generik, seperti yang disarankan berikutnya, akan sangat membantu. Dalam
diskusi berikut kita mengabaikan rincian fi ne harga, tetapi berkonsentrasi pada
aspek metering dan akuntansi.
4 sumber daya Abstrak
Kami menyarankan cara sistematis menggambarkan
model akuntansi sumber daya sehingga mereka dapat dipahami dan beralasan
tentang oleh konsumen. Ide utama adalah sangat sederhana: pertama
mendefinisikan satu set "dasar" sumber dikenakan biaya dan kemudian
menggambarkan konsumsi sumber daya keseluruhan sumber daya / layanan yang
diberikan dalam hal suatu agregasi dari konsumsi rokok dari sumber daya dasar.
Dengan pandangan ini dalam pikiran, kami menyajikan model konsumsi sumber daya
dari sumber daya abstrak.
Dengan beberapa sumber daya kecil tertentu
variasi fi c, model akuntansi sumber daya seperti S3, CSN dan EC2 dan sumber
daya lainnya tingkat infrastruktur dapat diwakili sebagai kasus khusus dari
model akuntansi sumber daya abstrak, dan karena itu dapat dipahami dan
beralasan tentang seragam cara.
Kami menganggap khas con fi gurasi mana server
(cloud) sumber daya dan sumber daya klien berinteraksi satu sama lain melalui
permintaan / tanggapan (req / res) dikirim melalui saluran komunikasi (lihat
Gambar 3). Seperti ditunjukkan dalam Figur, sumber daya
klien menggunakan wajah antar sumber daya server untuk menempatkan permintaan
dan mengumpulkan tanggapan yang sesuai. Penyebaran ini menimbulkan tiga jenis
biaya konsumsi: tra FFI konsumsi c, konsumsi operasi dan konsumsi sumber daya.
Tra FFI c konsumsi merupakan jumlah tra FFI c (sebagai contoh di MBytes) yang
dihasilkan oleh permintaan dan tanggapan pada saluran komunikasi. Konsumsi operasi
menangkap aktivitas yang dihasilkan oleh sumber daya klien pada antarmuka
seperti jumlah permintaan (juga disebut operasi) dan jumlah respon yang
dihasilkan. Akhirnya, konsumsi sumber daya merupakan konsumsi yang sebenarnya
dari sumber daya diukur dalam satuan yang bergantung pada sifat yang spesifik
dari sumber daya, misalnya, dalam satuan volume (misalnya, MBytes), waktu atau
kombinasi dari mereka (misalnya, MBytesHours).
Sebagai Figur menunjukkan, model akuntansi
sumber daya tertentu merupakan agregasi dari tiga model dasar: model untuk tra
FFI konsumsi c, model untuk konsumsi operasi dan model untuk konsumsi sumber
daya. Secara khusus, model akuntansi sumber daya tertentu akan sangat
consumer-centric jika semua tiga model mentary elemen yang berada sangat
consumer-centric. Model-model mentary elemen beroperasi secara independen satu
sama lain, sehingga mereka dapat dispesifikasikan dan diperiksa secara
terpisah.
Menggunakan model sumber daya abstrak sebagai
dasar, sekarang kita mengevaluasi model akuntansi dari tiga sumber daya
terindikasi sebelumnya untuk melihat apa rupa mereka cocok gagasan kita
akuntansi konsumen-sentris. Secara khusus, untuk setiap sumber daya yang kita
menentukan apakah ada penyebab yang dapat menyebabkan perbedaan antara data metering
yang dikumpulkan oleh penyedia dan konsumen.
5 model akuntansi S3
Ruang S3 diatur sebagai kumpulan ember yang
mirip dengan folder. Sebuah ember dapat berisi nol atau lebih objek hingga 5
terabyte data masing-masing. Kedua ember :
konsumsi
konsumsi
konsumsi
dan benda-benda yang diidentifikasi dengan nama
(kunci di Amazon ter- Gambar 3 Model Akuntansi sumber daya abstrak. minology)
yang dipilih oleh pelanggan. S3 menyediakan SOAP
dan antarmuka tenang. Sesuai dengan model
abstrak, sebuah Pelanggan S3 dibebankan untuk: a) sumber daya: ruang
penyimpanan yang dikonsumsi oleh benda-benda yang mereka simpan di S3; b)
traffic fi c: jaringan tra FFI c dihasilkan oleh operasi yang pelanggan
mengeksekusi terhadap antarmuka S3; dan c)
5.1 Penyimpanan sumber daya
Parameter kunci dalam perhitungan tagihan
penyimpanan jumlah jam byte dipertanggungjawabkan kepada pelanggan. Byte Jam
(ByteHrs) adalah jumlah byte bahwa cus- Tomer toko di akun mereka untuk
sejumlah tertentu jam. Amazon menjelaskan bahwa GB penyimpanan ditagih dalam
satu bulan adalah penyimpanan rata digunakan sepanjang bulan. Ini mencakup
semua data objek dan metadata disimpan dalam ember
yang Anda buat dalam account Anda. Kami
mengukur Anda penggunaan dalam TimedStorage-ByteHrs, yang ditambahkan pada akhir
bulan untuk menghasilkan biaya bulanan Anda. Selanjutnya, contoh yang
menggambarkan bagaimana menghitung tagihan Anda jika
Anda tetap 2684354560 byte (atau 2,5 GB) dari
data dalam Anda ember untuk seluruh bulan Maret disediakan. Dalam wajar sesuai menari
dengan Amazon jumlah byte yang dikonsumsi untuk setiap hari bulan Maret adalah
2684354560; sehingga total-angka
ber dari ByteHrs dihitung sebagai 2684354560 ×
31 × 24 = 1997159792640, yang setara dengan 2,5 GBMonths. Di
harga 15 sen per Giga Bytes per bulan, total biaya
sebesar 2,5 × 15 = 37,5 sen. Mereka lebih lanjut menyatakan bahwa setidaknya
dua kali sehari, kita periksa untuk melihat berapa banyak penyimpanan yang
digunakan oleh semua Anda Amazon S3 buck- ets. Hasilnya dikalikan dengan jumlah
waktu berlalu sejak pemeriksaan terakhir. Rekaman penyimpanan konsumsi tion di
ByteHrs dapat diambil dari Laporan Penggunaan terkait dengan setiap akun. Dari
definisi dari ByteHrs berikut bahwa perhitungannya culate tagihan mereka,
pelanggan perlu memahami 1) bagaimana Konsumsi byte mereka diukur, yaitu,
bagaimana data dan metadata yang diupload dipetakan menjadi dikonsumsi byte di
S3; dan 2) bagaimana Amazon menentukan nomor jam yang bagian tertentu dari data
yang disimpan dalam S3 –ini masalah secara langsung berkaitan dengan gagasan
pos pemeriksaan. Amazon menjelaskan bahwa setiap objek di S3 memiliki, selain data,
sistem metadata dan metadata pengguna; lebih jauh- semakin menjelaskan bahwa
metadata sistem yang dihasilkan dan digunakan oleh S3, sedangkan metadata pengguna
didefinisikan dan digunakan hanya oleh pengguna dan terbatas 2 KB ukuran [12].
Unfor- tunately, Amazon tidak menjelaskan bagaimana menghitung 295.198 bytes
1537 bytes dari data metadata Penyimpanan consump. dari Laporan Penggunaan:
295216 bytes Gambar 4 Dampak data dan metadata konsumsi storage.
Perhatikan bahwa dalam contoh ini, nama objek
dan ember masing-masing adalah, sepuluh dan delapan karakter panjang, yang
setara dengan sepuluh dan delapan byte, masing-masing.
Data objek dan metadata yang ditampilkan dalam
Figur corre- merespon terhadap informasi yang kami diambil secara lokal dari
permintaan PUT. Sebaliknya, konsumsi penyimpanan 295.216 byte sesuai dengan apa
yang kami temukan dalam Laporan Penggunaan. Laporan Penggunaan sebenarnya
menunjukkan konsumsi penyimpanan per hari di ByteHrs; nilai yang ditampilkan
adalah hasil dari versi con- ke dalam byte. Perhatikan bahwa konsumsi storage
ini sama dengan jumlah data objek, panjang nama objek dan panjang nama bucket:
8 + 10 + 295.198 = 295.216. Tiga kesimpulan yang bisa ditarik dari pengalaman-
ini KASIH: pertama, pemetaan antara byte upload (seperti
diukur dengan mencegat permintaan upload) dan
byte disimpan dalam S3 sesuai 00:59; kedua, stor- yang ruang usia ditempati oleh
sistem metadata adalah jumlah panjang (dalam Bytes) dari objek dan ember nama
dan dikenakan konsumsi storage; ketiga, metadata pengguna tidak Konsumsi
penyimpanan dampak. Singkatnya, untuk diberikan objek upload, konsumen dapat
secara akurat mengukur jumlah byte yang akan digunakan untuk menghitung ByteHrs.
Selanjutnya, kita perlu mengukur 'Jam' dari 'ByteHrs'. Sebagai dinyatakan
sebelumnya, Amazon menyatakan bahwa setidaknya dua kali sehari mereka memeriksa
jumlah penyimpanan yang dikonsumsi oleh pelanggan. Namun, Amazon tidak
menetapkan kapan tepatnya pemeriksaan berlangsung. Untuk memperjelas situasi,
kami melakukan sejumlah eksperimen yang terdiri di upload ke dan delet- ing fi
les dari S3 dan mempelajari Laporan Penggunaan rekening kami untuk mendeteksi
ketika dampak PUT dan operasi DELETE dipertanggungjawabkan oleh Amazon. Temuan
kami dirangkum dalam Gambar 5. Tampaknya, ruang penyimpanan yang sebenarnya
diambil oleh data dan metadata. Untuk clar- ify masalah ini, kami upload
sejumlah objek berlainan nama, data dan metadata pengguna ke jumlah yang sama ember
kosong. Gambar 4 menunjukkan parameter dan hasil dari salah satu operasi
meng-upload kita di mana sebuah benda bernama SC untuk tanggal 302x24 = 48GBHrs
SC untuk tanggal 315x24 = 120GBHrs SC
untuk 13x24 = 72GBHrs Object.zip diupload ke dalam ember bernama MYBUCKET, yang
semula kosong.
Saat ini, Amazon tidak benar-benar memeriksa
pemakaian storage pelanggan dua kali sehari saat mereka tentukan dalam mereka
Menghitung dokumen Bill Anda, tapi hanya sekali. Dari pengamatan kami,
terungkap bahwa saat pos pemeriksaan. Dalam Figur, CP singkatan pos
pemeriksaan, sehingga CP30: 2GB menunjukkan bahwa CP30 dilakukan pada hari
ke-30 bulan pada saat-spesifikasi ed oleh panah dan melaporkan bahwa dari data
metadata Consump Bandwidth. (DataTransferIn) dari laporan penggunaan: 295198
bytes pada saat itu pelanggan memiliki 2 GB disimpan di S3. SC berdiri untuk
Penyimpanan Konsumsi dan dijelaskan di bawah ini. Seperti ditunjukkan dalam
Figur, Amazon menggunakan hasil pro- diproduksi oleh sebuah pos pemeriksaan
dari hari tertentu, untuk account pelanggan untuk 24 jam dari hari itu,
terlepas dari oper tersebut negosiasi bahwa pelanggan mungkin melakukan selama
ini kiri antara pos pemeriksaan dan 23: 59: 59Z jam
hari. Sebagai contoh, konsumsi penyimpanan
untuk tanggal 30 akan diambil sebagai 2 × 24 = 48 GBHrs; dimana 2 merupakan 2GB
bahwa pelanggan upload pada tanggal 30 dan 24 mewakili 24 jam dari hari.
5.2 Tra FFI c
Amazon menjelaskan bahwa datatransfer-In adalah
jaringan data yang ditransfer dari pelanggan untuk S3. Mereka menyatakan Setiap
kali bahwa permintaan diterima untuk menempatkan objek, jumlah jaringan tra FFI
c terlibat dalam transmisi data objek, metadata, atau tombol dicatat di sini. Datatransfer-Out
adalah jaringan data ditransfer dari S3 kepada pelanggan. Mereka menyatakan bahwa
Setiap kali permintaan diterima untuk mendapatkan objek, jumlah jaringan tra
FFI c terlibat dalam transmisi data objek, meta Data, atau tombol dicatat di
sini. Dengan sini mereka berarti bahwa dalam Laporan Penggunaan terkait dengan
setiap account, Jumlah datatransfer-In dan datatransfer-Out gendererated oleh
pelanggan, diwakili, masing-masing, dengan yang datatransfer-In-Bytes dan
datatransfer-Out-Bytesparameter. Amazon menggunakan contoh untuk menunjukkan
bahwa jika Anda meng-upload satu 500 MB fi le setiap hari selama bulan Maret
dan Anda download satu 500 MB fi le setiap hari selama bulan Berbaris tagihan
Anda untuk Maret (bayangkan 2011) akan perhitungan teori diterjemahkan sebagai
berikut. The datatransfer-In akan 500MB × (1/1024) × 31 = 15.14GB. Dengan harga
10 sen per Giga Bytes, biaya keseluruhan mencapai 15,14 × 10 = 151,4 sen. Dalam
contoh kedua mereka menunjukkan bahwa jika Anda men-download satu 500 MB fi le
setiap hari selama bulan Maret total Jumlah datatransfer-Out akan 15.14 GB yang
dibebankan pada 15 sen per GB akan berjumlah 227 sen. Meskipun demikian tidak
jelas dari informasi yang tersedia bagaimana ukuran pesan dihitung. Untuk
memperjelas titik, kami upload sejumlah fi les dan dibandingkan informasi yang
diambil dari operasi PUT terhadap konsumsi bandwidth yang dihitung dalam
Laporan Penggunaan. dari data metadata Consump Bandwidth. (DataTransferIn) dari
laporan penggunaan:
Dua contoh dari percobaan yang kami lakukan
ditunjukkan pada Gambar 6: kami menggunakan operasi PUT untuk meng-upload
sebuah objek ke dalam ember. Data dan metadata yang ditunjukkan dalam Figur
mewakili data dan metadata diekstraksi secara lokal dari permintaan PUT. Seperti
yang ditunjukkan oleh consump Bandwidth. parameter diekstrak dari Laporan
Penggunaan, hanya data objek mengkonsumsi datatransfer-In bandwidth; baik data
meta atau nama objek atau ember tampaknya dihitung sebagai biaya overhead.
Pengamatan ini mengacu pada permintaan tenang. Sebaliknya, untuk pesan SOAP,
ukuran total pesan selalu digunakan untuk menghitung konsumsi bandwidth.
5.3 Operasi
Hal ini mudah bagi konsumen untuk menghitung
jenis dan jumlah operasi yang dilakukan pada S3. Untuk menggambarkan mereka pengisian
skema Amazon memberikan contoh dalam Ama- zon Simple Storage Service FAQ mana
Anda mentransfer 1000 fi les ke Amazon S3 dan mentransfer 2.000 fi les dari
Amazon S3 setiap hari selama bulan Maret, dan menghapus 5000files pada tanggal
31 Maret. Dalam skenario ini, jumlah Permintaan PUT dihitung 1000 × 31 = 31000,
sedangkan jumlah permintaan GET dihitung sebagai 2.000 × 31 = 62000. Jumlah
permintaan DELETE adalah sim- ply 5000 meskipun ini tidak relevan karena
permintaan DELETE adalah gratis. Dengan harga satu sen per 1.000 permintaan PUT
dan satu sen per 10000 permintaan GET, total biaya untuk operasi dihitung
sebagai 31000 × (1/1000) + 62000 × (1/10000) = 37,2 sen. Kami mencatat bahwa
operasi mungkin gagal untuk menyelesaikan SUC- cessfully. Respon kesalahan pada
umumnya mengandung masi mation yang membantu mengidentifikasi pihak yang
bertanggung jawab untuk Kegagalan: pelanggan atau infrastruktur S3. Untuk
meneliti ple, kesalahan NoSuchBucket disebabkan oleh pelanggan.
ketika mereka mencoba untuk meng-upload fi le
ke dalam ember tidak ada; sedangkan kode internalerror menunjukkan bahwa S3
expe- riencing masalah internal. Pemahaman kami adalah bahwa
30
PUT 2GB
PUT 1GB
31 Maret 1
konsumen dikenakan biaya untuk operasi, apakah
operasi berhasil atau tidak.
PUT 3GB DEL3GB
PUT 4GB
PUT 5GB
a)
CP: 6GB
cp: 6GB
cp: 7GB CP: 7GB
Untuk o ff er ketersediaan tinggi, Amazon
ulangan data di
30 30
31 31
beberapa server di dalam pusat data. Replika
yang
terus lemah konsisten dan sebagai hasilnya,
beberapa sempurna
operasi hukum kadang-kadang bisa gagal atau
kembali tidak akurat
SC untuk Mar = 6x24 + 7x24 = 312GBHrs sc Mar =
6x24 + 7x24 = 312GBHrs
Hasil (lihat [12], Data Konsistensi Model
seksi). Untuk
Misalnya, pelanggan mungkin menerima
ObjectDoesNotEx-
ist sebagai respon terhadap permintaan GET
hukum atau tidak lengkap
daftar objek setelah menjalankan operasi LIST.
Beberapa
30
PUT 2GB
PUT 1GB
PUT 3GB DEL3GB
31 Mar
PUT 4GB
01
PUT 5GB
masalah ini dapat diperbaiki dengan
re-mencoba-operasi yang
CP: 6GB
cp: 3GB
b) cp: 3GB CP: 7GB
tion. Dari model akuntansi Amazon, tidak jelas
siapa yang
30 30
31 31
menanggung biaya operasi gagal dan mencoba lagi
mereka.
Kami dieksekusi sejumlah operasi termasuk
valid dan tidak valid yang (misalnya,
penciptaan ember
dengan nama yang tidak valid dan dengan
nama-nama yang sudah ada).
Selanjutnya kita memeriksa Laporan Penggunaan
dan seperti yang kita harapkan,
kami menemukan bahwa Amazon dihitung baik
sukses dan gagal
operasi. Gambar 7 menunjukkan contoh operasi
bahwa kita dieksekusi dan bandwidth dan operasi
con
asumsi-bahwa hal ini menyebabkan sesuai dengan
Penggunaan yang
Laporan.
Dengan demikian, operasi gagal untuk membuat
ember itu con
Diasumsikan 574 byte untuk datatransfer-In dan
dan 514 byte
untuk datatransfer-Out. Angka-angka ini, sesuai
dengan
ukuran permintaan SOAP dan respon
masing-masing. Sebagai
ditunjukkan dalam Figur, kami juga menemukan
bahwa gagal oper
asi dikeluarkan konsumsi operasi dan dihitung
oleh
RequestTier2 parameter dalam Laporan
Penggunaan.
5.4 Potensi penyebab perbedaan
5.4.1 Penyimpanan
Karena, untuk perhitungan ByteHrs, saat pos
pemeriksaan ditentukan secara acak oleh Amazon dalam
00: 00: 00Z dan 23: 59: 59Z interval waktu,
waktu yang digunakan di sisi konsumen tidak perlu sesuai dengan yang di sisi
penyedia: penyebab potensial untuk perbedaan. Hal ini diilustrasikan dengan
bantuan Gambar 8.
MENCIPTAKAN MYBUCKET // MYBUCKET sudah ada
Tanggapan:
Consump Bandwidth. (DataTransferIn) dari
laporan penggunaan: 574 bytes
Consump Bandwidth. (DataTransferOut) dari
laporan penggunaan: 514 bytes
Operasi consump. (RequestTier2) dari laporan
penggunaan: 1
Gambar 7 Bandwidth dan operasi konsumsi operasi
gagal.
SC untuk Mar = 6x24 + 7x24 = 312GBHrs
sc Mar = 3x24 + 3x24 = 144GBHrs
Gambar 8 Dampak pos pemeriksaan.
The Figur menunjukkan waktu pelaksanaan PUT
empat dan satu operasi DEL dieksekusi oleh konsumen S3 selama dua hari terakhir
bulan Maret. Hari pertama April juga ditampilkan untuk kelengkapan. Untuk
mempermudah, Figur mengasumsikan bahwa operasi PUT awal adalah sangat pertama
dieksekusi oleh konsumen setelah membuka akun S3-nya. The Figur juga
menunjukkan spesifik poin di saat pemeriksaan dilakukan secara independen oleh
kedua pihak, yaitu, Amazon dan konsumen. Dengan demikian, CP dan cp mewakili
masing-masing, Amazon dan pos pemeriksaan konsumen; Bytes Giga ditampilkan di
samping CP dan cp menunjukkan konsumsi storage terdeteksi oleh titik cek.
Sebagai contoh, pada tanggal 30, Amazon melakukan pemeriksaan yang tentang lima
di pagi hari dan mendeteksi bahwa, pada waktu itu, pelanggan memiliki 6 GB
disimpan (CP30: 6GB). Pada hari yang sama, konsumen melakukan pemeriksaan nya
hanya setelah tengah hari dan mendeteksi bahwa, pada saat itu, ia harus
6 GB disimpan (cp30: 6GB). SC dan sc mewakili,
masing-masing, konsumsi penyimpanan untuk bulan Maret, dihitung dengan Amazon
dan konsumen, berdasarkan pemeriksaan mereka.
The Figur menunjukkan bahwa konsumsi
penyimpanan dihitung dengan Amazon dan konsumen kekuatan di ff er sig- ni fi
cantly tergantung pada jumlah dan sifat dari operasi yang dilakukan dalam
interval waktu yang ditentukan oleh pemeriksaan kedua pihak, misalnya, dalam
CP31 dan cp31.
Skenario) menunjukkan situasi yang ideal di
mana tidak ada con
Operasi Sumeria yang dijalankan dalam sepasang
cek
poin yang dilakukan pada 30 atau 31. Hasilnya
adalah bahwa
kedua belah pihak menghitung konsumsi storage
yang sama. Dalam con
trast, b) menunjukkan skenario yang lebih
buruk-kasus di mana DEL
operasi terjawab oleh CP30 dan dihitung oleh
cp30 dan
Operasi PUT terlewatkan oleh cp31 dan dihitung
oleh CP31; hasil ini adalah bahwa Amazon dan konsumen, menghitung SC dan sc,
masing-masing, seperti 312 GB dan 144 GB.
Idealnya, kali pemeriksaan Amazon harus dibuat
diketahui kepada konsumen untuk mencegah kesalahan seperti itu. Menyediakan
informasi ini untuk pos-pos pemeriksaan yang akan datang mungkin bukan pilihan
yang masuk akal untuk penyedia penyimpanan, informasi yang bisa
'disalahgunakan' oleh konsumen dengan menempatkan menghapus dan menempatkan
sekitar pos pemeriksaan dengan cara yang arti secara resmi mengurangi Sejauh
ini, angka konsumsi fi. Sebuah alternatif akan membuat waktu pos pemeriksaan
terakhir yang tersedia (misalnya, dengan melepaskan mereka hari berikutnya).
5.4.2 Dampak jaringan dan operasi latency
Dalam diskusi tentang perhitungan ByteHrs
(mengilustrasikan basisnya menggunakan Gambar 8), kita telah secara implisit
diasumsikan bahwa pelaksanaan PUT (masing-masing DELETE) operasi merupakan
ajang atom waktu yang kejadian adalah baik kurang atau lebih besar dari waktu
checkpoint ( yaitu, pena terjadi apa-operasi baik sebelum atau setelah pos
pemeriksaan). Hal ini memungkinkan kita untuk mengatakan bahwa jika waktu
pemeriksaan yang digunakan pada penyedia diketahui konsumen, maka konsumen
dapat mencocokkan ByteHrs fi gures dari provider. Namun, asumsi ini lebih
menyederhanakan sifat didistribusikan dari PUT (masing-masing DELETE) operasi.
Pada Gambar 9 kita secara eksplisit menunjukkan
jaringan dan pelaksanaan operasi latency untuk suatu operasi tertentu, mengatakan
PUT; juga, i, j, k dan l adalah penyedia sisi pos pemeriksaan kali digunakan
untuk ilustrasi. Asumsikan bahwa di sisi penyedia, hanya operasi selesai
diperhitungkan untuk disertakan dalam perhitungan dari ByteHrs; sehingga sebuah
pos pemeriksaan yang diambil pada waktu i atau j tidak akan termasuk operasi
PUT (PUT belum rampung), sedangkan sebuah pos pemeriksaan yang diambil pada
waktu k atau l akan. Apa yang terjadi di sisi konsumen akan tergantung pada
event (mengirim permintaan atau penerimaan respon) diambil untuk mewakili
terjadinya PUT. Jika memadatkan kali-dari pesan permintaan (PUT) dianggap
sebagai waktu terjadinya PUT, maka ByteHrs sisi konsumen
Pemberi
Konsumen
Gambar 9 Jaringan dan latency operasi.
Perhitungan pos pemeriksaan di waktu saya atau
j akan mencakup operasi PUT, perbedaan sejak penyedia tidak! Di sisi lain, jika
timestamp dari respon pesan itu dianggap sebagai waktu terjadinya PUT, maka
sebuah pos pemeriksaan pada waktu k tidak akan menyertakan PUT pengoperasian
(sedangkan provider memiliki), lagi-lagi perbedaan. Singkatnya, untuk operasi
yang terjadi su FFI sien dekat dengan waktu pemeriksaan, tidak ada jaminan
bahwa mereka mendapatkan memerintahkan identik pada kedua sisi sehubungan
dengan waktu pemeriksaan. Dengan asumsi kali pemeriksaan diketahui konsumen,
maka setiap perbedaan dapat diselesaikan di sisi konsumen dengan memeriksa
angka-angka konsumsi penyimpanan penyedia dan bekerja di luar tempat operasi
yang terjadi di sekitar kali pos pemeriksaan.
5.4.3 Operasi
Sebelumnya kami menyatakan bahwa itu adalah
mudah bagi konsumen untuk menghitung jenis dan jumlah operasi yang dilakukan
pada S3. Ada potensi untuk perbedaan yang disebabkan oleh jaringan latency:
operasi yang dipanggil 'su FFI sien dekat' dengan akhir periode akuntansi
(katakanlah i) dan dihitung oleh konsumen untuk periode itu, mungkin akan
dihitung sebagai per- terbentuk pada periode berikutnya (j mengatakan) oleh
penyedia jika karena latency, pesan doa ini tiba di periode j. Hal ini akan
menyebabkan biaya akumulasi untuk periode kedua tidak menjadi sama. Ini
sebenarnya bukan masalah, karena Amazon menggunakan timestamp dari pesan doa
untuk resolusi, sehingga konsumen dapat menyesuaikan penyedia Figur.
Salah satu sumber kemungkinan di FFI culty
tentang biaya untuk operasi adalah menentukan pihak bertanggung jawab atas
gagal negosiasi oper. Saat ini, keputusan ini diambil secara sepihak oleh
Amazon. Dalam hal ini, kami mengantisipasi dua sumber potensi konflik: DNS dan
propagasi penundaan. Seperti yang dijelaskan oleh Amazon, beberapa permintaan
akan gagal dan pro Duce Temporary Redirect (kode HTTP 307 error) karena
kesalahan routing yang sementara yang disebabkan oleh penggunaan nama DNS
alternatif dan permintaan pengalihan teknik-teknik [13]. Saran Amazon adalah
untuk merancang aplikasi yang dapat menangani mengarahkan kesalahan, misalnya
dengan mengirim ulang permintaan setelah menerima 307 kode (lihat [12],
Permintaan Rout- ing bagian). Sebenarnya kesalahan ini tidak disebabkan oleh
pelanggan sebagai 307 kode menunjukkan. Hal ini tidak jelas bagi kita yang
menanggung biaya operasi ulang mencoba.
5.5 Ringkasan
Singkatnya, kita dapat mengatakan bahwa model
dua elemen
sumber mentary untuk tra FFI c dan konsumsi
operasi
dapat dianggap kuat konsumen-sentris, tapi suf-
fer bentuk ketidaklengkapan dan ketidakjelasan
(yang kita miliki
menunjukkan) dan model untuk sumber daya
penyimpanan konsumsi
tion adalah lemah konsumen-sentris
(checkpointing acara
tidak bisa diamati), membuat model keseluruhan
lemah
konsumen-sentris.
6 model akuntansi CSN
Sebuah ruang Nirvanix CSN diatur sebagai
kumpulan ers fold- yang mendukung bersarang. Folder dapat berisi nol atau lebih
subfolder dan file-file hingga 250 GB [14]. Kedua folder dan file-file yang
diidentifikasi dengan nama yang dipilih oleh pelanggan. Nirvanix CSN
menggunakan konsep model akuntansi yang hampir sama dengan yang digunakan oleh
Amazon S3; Namun, dibandingkan dengan Amazon, informasi tentang harga dan skema
pengisian digunakan untuk menghitung tagihan pelanggan yang jarang
didokumentasikan. Dari tiga sumber dasar dikenakan biaya diidentifikasi untuk
sumber daya abstrak, sebuah Konsumen Electrolux CSN dibebankan hanya untuk
konsumsi penyimpanan dan tra FFI c (tidak ada biaya untuk konsumsi operasi).
Kami melakukan pengukuran konsumsi sumber daya untuk penyimpanan dan jaringan
tra FFI c menggunakan jenis yang sama dari iments exper- seperti yang
dijelaskan untuk S3.
Seperti Amazon, untuk penyimpanan, Nirvanix
menggunakan GB / Bulan untuk menghitung tagihan, sehingga pelanggan perlu
memahami:
1) bagaimana konsumsi GB diukur, yaitu,
bagaimana data dan metadata yang diupload dipetakan ke dalam byte yang
dikonsumsi; dan 2) bagaimana Nirvanix menentukan jumlah jam yang bagian
tertentu dari data yang disimpan di CSN (seberapa sering dan kapan pemeriksaan
diambil). Mengenai 1), penelitian kami menunjukkan bahwa peta- ping antara byte
diunggah oleh permintaan PUT dan byte disimpan dalam CSN adalah satu-ke-satu;
kedua, pengguna dan sistem metadata tidak mempengaruhi konsumsi storage.
Concern- ing 2), meskipun Nirvanix tidak memberikan rincian tentang kapan pos
pemeriksaan mereka berlangsung, percobaan kami menunjukkan bahwa Nirvanix
menghitung konsumsi penyimpanan di titik awal setiap interval konsumsi 24 jam
(di
00:00:00 GMT). Mengenai tra FFI biaya c,
percobaan mengungkapkan bahwa hanya ukuran data dihitung dan tidak metadata
maupun fi le atau nama folder berkontribusi biaya.
Dengan demikian, mengingat informasi di atas,
konsumen dapat secara akurat mengukur konsumsi penyimpanan angka-angka dan
biaya tra FFI c; maka kita mempertimbangkan model sangat consumer-centric.
Model akuntansi 7 EC2
EC2 adalah layanan komputasi o ff ered oleh
Amazon sebagai IaaS [15]. Layanan o ff ers CPU virtual yang baku bagi konsumen.
Seorang konsumen diberikan hak akses administratif atas CPU maya, bahwa ia bisa
latihan dengan cara mengirimkan perintah remote ke Amazon Cloud dari komputer
desktop-nya. Sebagai contoh, ia diharapkan untuk con fi ure g-, peluncuran,
berhenti, kembali peluncuran, menghentikan, backup, dll CPU maya. Sebagai
imbalannya, konsumen bebas memilih sistem operasi (misalnya Windows atau Linux)
dan Penerapan-penerapan untuk menjalankan. Dalam terminologi EC2, CPU virtual
yang berjalan disebut Instance Virtual Machine (VMI) atau hanya sebuah contoh
sedangkan bundel beku software pada disk yang berisi perpustakaan, aplikasi dan
pengaturan guration con fi awal yang digunakan untuk meluncurkan sebuah contoh
disebut Amazon Mesin Gambar (AMI). Saat ini, Amazon o ff ers enam jenis kasus
yang di ff er satu sama lain dalam empat parameter guration con fi awal yang
tidak dapat diubah pada saat menjalankan: jumlah EC2 unit menghitung yang
memberikan, ukuran memori dan penyimpanan lokal (juga disebut penyimpanan
sementara dan contoh) dan jenis platform (32 atau 64 bit). Sebuah unit EC2
komputasi merupakan unit Amazon dan didefinisikan sebagai kapasitas CPU setara
dengan 1.0- 1,2 GHz Opteron 2007 atau 2007 prosesor Xeon. Dengan demikian
Amazon o ff er kecil, besar, ekstra jenis besar dan lain hal. Sebagai contoh,
tipe standar contoh adalah Instance Kecil dan platform 32 bit yang telah
dijalankan ers Unit menghitung 1 EC2 dan dilengkapi dengan 1,7 GB memori dan
160 GB penyimpanan lokal. Jenis kasus yang o ff ered kepada konsumen di bawah
beberapa model penagihan: kasus on-demand, contoh milik dan contoh tempat.
Dalam diskusi kami, kami akan fokus pada kasus on-demand. Berdasarkan model
penagihan on-demand, Amazon mendefinisikan unit konsumsi contoh sebagai contoh
jam (instanceHr). Saat ini, biaya satu jam instance dari contoh kecil yang
menjalankan Linux atau Windows, adalah, masing-masing, 8,5 dan 12 sen. Di atas
biaya selama berjam-jam misalnya, misalnya konsumen biasanya dikenakan biaya
addi- nasional untuk data tranfer bahwa kasus ates gener- (Data Transfer-In dan
Transfer Data-Out) dan infrastruktur addtional bahwa contoh mungkin perlu
seperti penyimpanan disk, alamat IP, fasilitas monitoring dan lain- lain.
Karena ini biaya tambahan dibukukan dan ditagih secara terpisah, kita akan
meninggalkan mereka keluar dari diskusi kita dan hanya fokus pada jam misalnya
biaya.
Sebuah angka-angka di atas menyiratkan bahwa
jika konsumen mencatat 10 instanceHrs dari konsumsi contoh kecil, menjalankan
Linux, selama satu bulan, ia akan dikenakan biaya 85 sen pada akhir bulan. Pada
prinsipnya, tabel harga yang tersedia untuk publik dari halaman web Amazon
harus memungkinkan konsumen untuk secara independen melakukan akuntansi sendiri
konsumsi EC2. Dengan tidak adanya fi model akuntansi didefinisikan dengan baik
de ini bukan latihan sepele.
Wawasan ke dalam model akuntansi EC2 tersebar
di beberapa dokumen on-line dari Amazon. Beberapa wawasan definisi dari contoh
jam tersedia dalam dokumen Harga Amazon EC2 [16] (lihat di bawah tabel Contoh
On-demand) di mana dinyatakan bahwa ing Pric- adalah per contoh-jam dikonsumsi
untuk setiap contoh, dari saat sebuah contoh diluncurkan sampai diakhiri.
Setiap parsial misalnya jam dikonsumsi akan ditagih sebagai jam penuh.
Pernyataan ini menunjukkan bahwa setelah sebuah contoh diluncurkan itu akan
dikenakan setidaknya contoh jam menyebabkan konsumsi rokoknya. Sebagai contoh,
jika misalnya berjalan terus menerus selama 5 menit, itu akan dikenakan 1
instanceHrs; juga, jika contoh berjalan terus menerus selama 90 menit, itu akan
dikenakan 2 instanceHrs.
Masalah dengan hal ini definisi adalah bahwa
hal itu tidak menjelaskan kapan sebuah contoh dianggap akan diluncurkan dan
diakhiri. Informasi tambahan tentang masalah ini diberikan di bagian Penagihan
FAQ [17], Membayar untuk Apa yang Anda Gunakan Amazon Elastic Compute (Ama- zon
EC2) dokumen [15] dan pada bagian Bagaimana Kau Dibebankan dari Panduan
Pengguna [18]. Misalnya, dalam [15] disebutkan bahwa Setiap contoh akan
menyimpan waktu peluncuran yang sebenarnya. Setelah itu, masing-masing instance
akan mengenakan biaya untuk jam nya cution exe- pada awal setiap jam relatif
terhadap waktu yang diluncurkan.
Dari informasi yang diperoleh dari
dokumen-dokumen yang dikutip di atas jelas bahwa Amazon mulai dan berhenti
menghitung jam misalnya sebagai contoh didorong oleh konsumen, melalui negara
erent di ff. Selain itu, jelas bahwa jam Amazon contoh yang masih harus dibayar
dari pelaksanaan satu atau lebih sesi individu dieksekusi oleh konsumen selama
periode penagihan. Dalam konteks ini, sesi dimulai dan berakhir ketika
meluncurkan konsumen dan berakhir, masing-masing, sebuah contoh. Model
akuntansi berbasis Session sumber daya yang melibatkan beberapa peristiwa dan
negara-negara yang dikenakan di ff eh konsumsi ent, yang nyaman dijelaskan oleh
Machines Negara Finite (FSMs). Kami akan menggunakan pendekatan ini untuk
menggambarkan model akuntansi EC2. Lainnya, misalnya RightScale (broker layanan
cloud), juga mengambil pendekatan ini [19].
7.1 Serikat sesi instance
Negara-negara yang menjadi contoh dapat
mencapai selama sesi tergantung pada jenis memori yang digunakan oleh AMI untuk
menyimpan boot (juga disebut root) perangkat tersebut. Saat ini, Amazon
dukungan port S3 yang didukung dan contoh EBS yang didukung. EBS berdiri untuk
Elastic Block Store dan merupakan penyimpanan persisten yang dapat dilampirkan
ke sebuah contoh. Konsumen memilih antara S3 atau contoh EBS yang didukung pada
penciptaan AMI waktu. Sayangnya, negara-negara yang contoh dapat mencapai
dur-ing sesi tidak terdokumentasi dengan baik oleh Amazon. Namun setelah
pemeriksaan hati-hati dokumenter online Amazon tasi kami berhasil membangun FSM
ditunjukkan pada Gambar 10a). FSM sebuah contoh Amazon mencakup dua jenis negara:
negara permanen dan sementara. Negara permanen (Diwakili oleh lingkaran besar,
misalnya berjalan) dapat jarak jauh dimanipulasi oleh perintah yang dikeluarkan
oleh konsumen; sekali FSM mencapai keadaan yang permanen, tetap di sana sampai konsumen
mengeluarkan perintah untuk memaksa FSM ke kemajuan ke negara bagian lain. Keadaan
transient (diwakili oleh lingkaran kecil, misalnya berhenti) yang menyatakan
bahwa kunjungan FSM sementara yang berkembang dari negara tetap menjadi yang
lain. Konsumen tidak memiliki kontrol atas waktu yang dihabiskan dalam keadaan
transien; ini adalah mengapa tidak ada label pada panah keluar dari negara
tersebut.
Kami telah diberi label transisi dari FSM
dengan notasi acara / tindakan. Acara ini adalah penyebab dari masa transisi
sedangkan tindakan merupakan himpunan (mungkin kosong) operasi yang Amazon
mengeksekusi ketika peristiwa itu terjadi, untuk menghitung jumlah jam misalnya
dikonsumsi oleh contoh.
Ada dua jenis acara: konsumen dan internasional
nal dengan peristiwa FSM. Peristiwa konsumen adalah perintah (peluncuran,
perintah aplikasi, reboot, berhenti dan mengakhiri) bahwa isu-isu konsumen
untuk mengoperasikan contoh nya; juga, peristiwa internal peristiwa yang
terjadi secara independen dari perintah konsumen, yaitu, timer = 60menit dan
kegagalan. Sebuah diskusi tentang semua usaha tetap dan beberapa negara
transient digambarkan dalam FSM berikut.
• AMI con fi gurasi: adalah keadaan awal. Hal
ini dicapai ketika konsumen berhasil con fi gures AMI nya sehingga siap
diluncurkan.
• Menjalankan: adalah negara di mana contoh
dapat melakukan perhitungan yang berguna bagi konsumen, misalnya, dapat
merespon perintah aplikasi yang dikeluarkan oleh konsumen.
• Dihentikan: adalah keadaan nal fi dan
merupakan akhir dari siklus hidup contoh. Setelah keadaan ini tercapai contoh
hancur. Untuk melakukan perhitungan tambahan setelah memasuki negara ini
konsumen perlu menipu Figur AMI lain. Negara dihentikan tiba saat berlangganan
yang mengeluarkan mengakhiri perintah, misalnya gagal bila dalam menjalankan
negara atau contoh gagal untuk mencapai menjalankan negara.
• Tertunda: berkaitan dengan Instansiasi contoh
dalam awan Amazon. Tertunda mengarah ke menjalankan negara ketika misalnya
berhasil dipakai atau negara dihentikan ketika Amazon gagal untuk instantiate
contoh.
• Shuttingdown: tercapai bila konsumen
mengeluarkan mengakhiri perintah.
• Berhenti: Negara ini didukung kasus hanya EBS
yang didukung (contoh S3 yang didukung tidak dapat dihentikan) dan dicapai
ketika masalah pengguna menghentikan perintah, katakanlah misalnya, untuk
melakukan tugas-tugas cadangan.
• Reboot: tercapai bila konsumen mengeluarkan perintah
reboot.
7.2 Negara dan jam misalnya
Dalam Figur, NinstHrs digunakan untuk
menghitung jumlah jam misalnya dikonsumsi oleh sebuah contoh saat suatu single Sesi
gle. Jumlah jam misalnya dikonsumsi oleh contoh ditentukan oleh nilai integer
yang disimpan dalam NinstHrs ketika misalnya mencapai negara dihentikan. timer
Amazon untuk menghitung interval 60 menit; dapat diatur ke nol (waktu = 0) dan
mulai (starttimer).
Dalam FSM, operasi pengisian dieksekusi sebagai
nyarankan- gested oleh dokumentasi Amazon line. Misalnya, dalam Membayar Apa
yang Anda Gunakan Seksi [15], Amazon menyatakan bahwa awal satu jam misalnya
adalah relatif terhadap waktu peluncuran. Akibatnya, FSM menetapkan NinstHrs =
1 ketika konsumen mengeksekusi perintah peluncuran dari AMI con fi gurasi
negara. Pada saat yang sama, timer diatur ke nol dan mulai. NinstHrs = 1
menunjukkan bahwa sekali konsumen dalam mengeksekusi perintah peluncuran, ia
akan dikenakan setidaknya satu contoh jam. Jika konsumen meninggalkan contoh di
negara berjalan selama 60 menit (waktu = 60menit) increment FSM NinstHrs per
satu, set timer ke nol dan mulai lagi. Dari menjalankan negara timer diatur ke
nol ketika konsumen memutuskan untuk mengakhiri contoh nya (mengakhiri
perintah) atau ketika misalnya gagal (kegagalan event). Meskipun dokumentasi
Amazon tidak dis menyumpahi itu, kami percaya bahwa kemungkinan contoh tidak
mencapai keadaan berjalan tidak dapat diabaikan, karena itu kami telah
menyertakan transisi dari tertunda negara dihentikan; FSM set timer ke nol
ketika peristiwa normal ini terjadi.
Sebagaimana dijelaskan dalam Dasar-dasar dari
Amazon EBS-Beragun Amis dan Contoh dan Bagaimana Kau Dibebankan dari [18], yang
menjalankan EBS yang didukung misalnya dapat dihentikan oleh konsumen melalui
perintah berhenti dan mengendarainya ke keadaan berhenti. Seperti yang
ditunjukkan oleh waktu = 0 operasi dijalankan ketika berlangganan mengeluarkan
perintah berhenti, sebuah contoh dalam keadaan berhenti menimbulkan tidak ada
contoh jam. Namun, meskipun tidak ditampilkan dalam Figur karena ini adalah
masalah erent di ff, Amazon biaya untuk penyimpanan EBS dan jasa tambahan lain
yang berkaitan dengan contoh dihentikan. Konsumen dapat menggerakkan sebuah
contoh dari berhenti untuk negara dihentikan. Atau dia bisa memulai kembali
contoh nya. Bahkan, konsumen bisa memulai, berhenti dan memulai contoh nya
sebanyak dia perlu. Namun, seperti yang ditunjukkan oleh NinstHrs + +, timer =
0 dan starttimer operasi selama panah, setiap transisi dari berhenti untuk menunggu
negara timbul satu jam misalnya konsumsi, apapun waktu yang telah berlalu
antara setiap pasangan perintah peluncuran berturut-turut.
7.3 Percobaan dengan contoh Amazon
Untuk memverifikasi bahwa model akuntansi yang
dijelaskan oleh FSM Gambar 10a) cocok deskripsi Amazon, kita (sebagai konsumen)
melakukan serangkaian eksperimen praktis. Secara khusus, tujuan kami adalah
untuk memastikan bagaimana jumlah jam misalnya dihitung oleh Amazon. Percobaan
melibatkan 1) con fi gurasi berlainan Amis; 2) peluncuran contoh; 3)
pelaksanaan com- jarak jauh mands untuk mendorong kasus melalui negara erent di
ff ditunjukkan dalam FSM. Sebagai contoh, kita con fi gurasi Amis, meluncurkan
dan menjalankan mereka untuk periode di ff panjang erent dan diakhiri mereka. Demikian
juga, kami meluncurkan contoh dan diakhiri mereka segera setelah mereka
mencapai keadaan berjalan. Untuk menghitung jumlah jam misalnya dikonsumsi oleh
contoh, kami mencatat waktu pelaksanaan perintah terpencil luncurkan, berhenti,
menghentikan dan reboot, dan waktu mencapai negara baik sementara dan permanen.
Sebagai perbandingan, kami mengumpulkan data (mulai dan waktu akhir jam
misalnya, dan jumlah jam misalnya dikonsumsi) dari Amazon EC2 laporan
penggunaan. Perbandingan data yang dikumpulkan dari eksperimen kami dengan data
Amazon dari laporan penggunaannya mengungkapkan bahwa saat ini, awal satu jam
misalnya bukan waktu pelaksanaan perintah peluncuran konsumen, seperti yang
didokumentasikan oleh Amazon, tapi saat instance mencapai menjalankan negara.
Temuan ini menyiratkan bahwa model akuntansi saat ini sedang digunakan adalah
yang dijelaskan oleh FSM Gambar 10b). Seperti ditunjukkan dalam Figur, yang
NinstHrs bertambah ketika misalnya mencapai keadaan berjalan.
7.4 Potensi penyebab perbedaan
Ketidaksesuaian antara Amazon didokumentasikan
pertanggungjawaban ing model dan satu yang sedang digunakan (Gambar 10a dan b,
masing-masing) dapat mengakibatkan perbedaan antara konsumen dan perhitungan
Amazon jam misalnya. Sebagai contoh, bayangkan bahwa dibutuhkan lima menit
untuk mencapai menjalankan negara. Sekarang bayangkan bahwa peluncuran konsumen
sebuah contoh, daun itu berjalan selama 57 menit dan kemudian berakhir itu.
Dengan asumsi sisi konsumen menggunakan FSM Gambar 10a), NinstHrs konsumen akan
sama dengan dua: NinstHrs = 1 pada saat peluncuran dan kemudian NinstHrs adalah
bertambah saat timer = 60menit. Sebaliknya, dengan kepuasan konsumen, catatan
penggunaan Amazon akan menunjukkan hanya satu jam misalnya konsumsi. Satu bisa
berdebat bahwa perbedaan ini tidak menjadi perhatian konsumen karena, ekonomi,
selalu berpihak kepadanya. Lebih menantang dan lebih dekat dengan kekhawatiran
konsumen adalah perbedaan yang disebabkan oleh kegagalan. Dokumenter Amazon tasi
tidak mengatur bagaimana contoh yang gagal merupakan penghasilan Misalnya jam.
Misalnya, memeriksa Gambar 10a) dan membayangkan bahwa sebuah contoh tiba-tiba
crash setelah belanja 2 jam dan 15 menit dalam menjalankan negara. Hal ini
tidak jelas bagi kami apakah Amazon akan mengenakan biaya untuk 15 menit
terakhir eksekusi sebagai contoh jam secara keseluruhan. Sebagai contoh kedua, membayangkan
bahwa setelah diluncurkan baik dari AMI con fi g- ured atau negara dihentikan,
sebuah contoh berkembang menjadi tertunda negara dan dari sana, karena
kegagalan, untuk dihentikan. Itu adalah tidak jelas bagi kami jika Amazon akan
mengenakan biaya untuk contoh terakhir jam dihitung oleh NinstHrs. Kami percaya
bahwa, terlepas dari kelalaian ini tentang fail situasi ure, model akuntansi
Gambar 10a) dapat diimplementasikan dan digunakan oleh konsumen untuk
memproduksi akurat akuntansi tingkat. Sebuah fitur penting dari model ini
adalah bahwa semua peristiwa (peluncuran, berhenti dan mengakhiri) dampak
counter NinstHrs dihasilkan oleh konsumen. Satu-satunya perkecualian jika timer
event = 60menit, tapi itu bisa vis ible kepada konsumen jika ia mensinkronisasi
jam untuk waktu UTC. Model akuntansi yang benar-benar Amazon menggunakan
(Gambar 10b) tidak dipengaruhi oleh kegagalan contoh untuk mencapai menjalankan
negara karena dalam model ini, NinsHrs bertambah ketika misalnya mencapai
menjalankan negara. Namun, model ini lebih sulit bagi konsumen untuk
melaksanakan ment sejak peristiwa yang menyebabkan contoh untuk kemajuan dari
tertunda untuk menjalankan negara tidak berada di bawah kendali konsumen.
7.5 Ringkasan
Singkatnya, model akuntansi EC2 adalah lemah konsumen-sentris:
konsumsi tra FFI c dan operasional model konsumsi tion yang sangat
consumer-centric (Model konsumsi operasi justru dispesifikasikan - tidak ada
biaya!), tetapi model konsumsi sumber daya adalah lemah konsumen-sentris
karena, seperti yang kita dijelaskan dengan sehubungan dengan Gambar 10b, acara
yang menyebabkan virtual Mesin contoh untuk kemajuan dari pending untuk
menjalankan Negara tidak terlihat konsumen.
8. Mengembangkan model konsumen-sentris Sangat
model akuntansi konsumen-sentris memiliki sifat yang diinginkan keterbukaan dan
transparansi, karena pengguna jasa berada dalam posisi untuk memverifikasi
tuduhan ditagih kepada mereka. Penyelidikan kami menunjukkan penyebab yang
dapat menyebabkan perbedaan antara data metering yang dikumpulkan oleh konsumen
tidak cocok dengan provider. Essen- tially penyebab ini dapat digolongkan dalam
tiga kategori dibahas di bawah.
1. Kekurangan kelengkapan dan ambiguitas: Hal
ini tentu saja perlu bahwa konsumen diberikan dengan model akuntansi sumber
daya jelas bahwa justru menggambarkan semua sumber daya konstituen dikenakan
biaya layanan dan bagaimana biaya penagihan dihitung dari penggunaan sumber
daya (konsumsi sumber daya) data yang dikumpulkan atas nama dari konsumen
selama periode waktu tertentu. Kami menunjukkan beberapa kasus di mana model
akuntansi spesifik kasi ambigu atau tidak lengkap. Sebagai contoh, untuk S3,
mengenai konsumsi bandwidth, tidak jelas
dari informasi yang tersedia apa yang merupakan
ukuran dari pesan. Hal ini hanya melalui eksperimen kami bekerja di luar bahwa
untuk operasi tenang, hanya ukuran objek diperhitungkan dan sistem dan metadata
pengguna bukan bagian dari ukuran pesan, sedangkan untuk operasi SOAP, ukuran
total pesan yang dibawa ke akun. Penanganan Kegagalan adalah daerah lain di
mana ada kurangnya informasi dan / atau kejelasan: misalnya, tentang EC2, tidak
jelas bagaimana kasus yang gagal merupakan penghasilan jam misalnya.
2. peristiwa tidak teramati: Jika model
akuntansi menggunakan satu atau lebih peristiwa yang konsumsi sumber daya
dampak, namun peristiwa ini tidak dapat diamati (atau terjadinya mereka tidak
dapat diperkirakan secara akurat oleh) konsumen, maka data yang dikumpulkan di
sisi konsumen bisa di ff er dari yang provider. Perhitungan konsumsi
penyimpanan di S3 (ByteHrs) adalah contoh yang baik: di sini, acara pemeriksaan
tidak bisa diamati.
3. perbedaan-perbedaan Di ff dalam proses
pengukuran: Di ff selisih dapat timbul jika kedua belah pihak menggunakan
teknik di ff erent untuk pengumpulan data. Perhitungan BytHrs lagi berfungsi
sebagai contoh yang baik. Kami berharap bahwa untuk pos pemeriksaan, penyedia
langsung akan mengukur ruang penyimpanan sebenarnya diduduki, sedangkan, untuk
diberikan waktu pemeriksaan, konsumen akan meniru proses dengan menambahkan
(untuk PUT) dan mengurangkan (untuk DELETE) untuk menghitung ruang, dan seperti
yang kita bahas sehubungan dengan Permasalahan yang diangkat di atas dapat
langsung ditangani oleh penyedia yang ingin membangun model konsumen-sentris.
Mereka harus menggunakan model sumber daya abstrak sebagai dasar untuk
membangun model akuntansi layanan seperti itu akan memperkenalkan banyak
dibutuhkan struktur ke-spesifikasi ca- tion dimaksudkan untuk menggambarkan
semua sumber daya konstituen dikenakan biaya. Untuk layanan yang melewati
beberapa negara sitions transponder (seperti EC2), penyedia harus secara
eksplisit memberikan FSM deskripsi berbasis. Selanjutnya, mereka harus
memastikan, sebanyak mungkin, bahwa model mereka tidak bergantung pada
unobserv- mampu (untuk konsumen) acara untuk perhitungan biaya penagihan.
Akhirnya, penyedia harus melalui latihan membangun layanan pengukuran pihak
ketiga untuk melihat apakah data metering yang diperlukan dapat dikumpulkan
dengan mudah dan bahwa hal itu sesuai dengan data sisi penyedia dengan su FFI
efisien presisi. Setiap perbedaan yang mendapatkan diperkenalkan secara tidak
sengaja (misalnya, karena identik kali non titik cek) dapat diselesaikan oleh
konsumen dengan pemeriksaan yang cermat data penggunaan sumber daya yang sesuai
dari penyedia. Mereka yang tidak bisa diselesaikan akan menunjukkan kesalahan
pada sisi konsumen dan / atau penyedia menyebabkan perselisihan.
9 Memperkirakan dan memverifikasi biaya
penagihan
Kami mencatat bahwa banyak penyedia layanan
cloud membuat terse- dia petunjuk tagihan kalkulator untuk memperkirakan biaya
untuk menggunakan sumber daya mereka awan. AWS Sederhana Bulanan perhitungan
teori lator [20] adalah contoh yang baik. Kami percaya bahwa model akuntansi
sumber daya abstrak menyediakan titik awal yang baik untuk mengembangkan alat
biaya estimasi otomatis yang dapat mengambil informasi tentang sumber daya dan
cara mereka telah terhubung dan con fi gurasi dan menggunakan informasi yang
untuk memperkirakan biaya untuk spesifik pola penggunaan c.
Alat tersebut dapat digunakan oleh konsumen
untuk memperoleh biaya-e ff efektif sumber daya con gurations fi sebelum
benar-benar deploy- ing mereka di awan. Alat ini dapat diintegrasikan dengan
sisi konsumen sistem akuntansi sumber daya dari jenis yang digambarkan dalam
Gambar 2 untuk memverifikasi biaya penagihan selama jangka waktu. Peningkatan
lebih lanjut yang mungkin dengan incorpo- Peringkat penyesuaian dinamis dari
kapasitas sumber daya throughput keluar siklus hidup aplikasi berbasis cloud
untuk tetap dalam batas-batas beberapa biaya yang telah ditentukan. Kami
nyarankan- gest ini sebagai petunjuk untuk pekerjaan di masa depan, dan
menggunakan penyebaran hipotetis ditunjukkan pada Gambar 11 untuk menyoroti
beberapa masalah teknis yang terlibat.
Penyebaran Gambar 11 melibatkan kation appli
klien yang memanfaatkan tiga jenis Amazon sumber dasar: penyimpanan S3, EC2
VMIs dan elastis Blok Storage (EBS) volume. Beberapa kata-kata di EBSs: ini
adalah volume usia blok stor- gigih sering digunakan untuk membangun fi le
sistem dan database. Mereka mendukung dua antarmuka: Web ser wakil antarmuka
dan antarmuka input / output berdasarkan blok. Antarmuka layanan Web dapat
digunakan oleh klien untuk mengeluarkan (misalnya, dari aplikasi desktop-nya)
operasi iatan admin-, seperti membuat volume, menghapus sukarela ume,
melampirkan volume, melepaskan volume, dll masukan berbasis block / output
antarmuka dapat digunakan oleh EC2 VMIs dan menjadi tersedia atas melampirkan
EBS ke VMI. Seorang konsumen dari EBS dibebankan untuk konsumsi operasi (diukur
sebagai jumlah operasi input / output bahwa tempat EC2 VMI terhadap EBS) dan
con sumber daya sangkaan (GB-bulan, di mana durasi ditentukan sebagai waktu
yang berlalu antara penciptaan dan penghapusan EBS).
Untuk perhitungan biaya penagihan, beberapa
informasi yang relevan pada struktur fisik awan dan pengisian kebijakan
penyedia diperlukan. Mengambil Amazon sebagai kasus, awan mereka dibagi menjadi
daerah yang lokasi ical phys- geografis (misalnya AS-Timur di Northern Virginia,
AS-Barat di California Utara, Uni Eropa di Irlandia). EC2 awan dibagi dalam
zona yang pusat data kegagalan-independen yang terletak di dalam wilayah Amazon
dan dihubungkan oleh jaringan latency rendah.
Mengenai harga, secara umum, Amazon biaya untuk
tra FFI c masuk dan keluar (Data Transfer-In dan Data transfer- Out
masing-masing) dari awan Amazon dan tra FFI c masuk dan keluar dari awan EC2.
Namun, Amazon tidak mengenakan biaya untuk tra FFI c antara VMI dan sumber daya
lain (mengatakan S3) yang terletak di wilayah yang sama. Juga tidak mereka
tetapkan untuk tra FFI c antara dua VMIs terletak di dalam zona ketersediaan
yang sama. Namun, Amazon biaya untuk antar-wilayah tra FFI c antara VMI dan
sumber daya lain (misalnya, S3) berlokasi di kawasan erent di ff. Dalam situasi
ini, pengirim data akan dikenakan biaya untuk Transfer Data-Out sedangkan
penerima akan dikenakan biaya untuk Transfer Data-In.
Penyebaran yang ditunjukkan pada Gambar 11
melibatkan dua daerah Ama- zon (US Timur dan Barat AS) dan dua zona
ketersediaan (av-zoneA dan av-zoneB) terletak di wilayah Barat AS. Garis
arrowed merupakan saluran komunikasi dua arah. Dihilangkan dari Figur adalah
saluran komunikasi yang digunakan oleh klien untuk mengeluarkan perintah
administratif kepada VMIs (peluncuran, berhenti, reboot, dll) dan EBS (membuat
volume, pasang volume, dll).
Kami membuka diskusi ini dengan studi tentang
biaya yang berlaku untuk EBS1 dan EBS2. Bayangkan demi argumen bahwa mereka
adalah volume 50 GB dan 100 GB, masing-masing. Dari perhatian kita di sini
adalah operasi menyebabkan konsumsi rokoknya dan waktu konsumsi EBSs. EBS1 akan
Amazon awan wilayah Barat AS dikenakan biaya untuk jumlah input / output
operasi
bahwa tempat VMI1 terhadap antarmuka EBS1 dan
juga untuk jangka waktu pemakaian yang dialokasikan 50 GB. Menjadi saat
terpisah, biaya untuk EBS2 lebih sederhana untuk menghitung, hanya terdiri dari
konsumsi waktu untuk 100 GB. Dengan kebijakan harga dalam pikiran, mari kita
mempelajari biaya untuk VMI1. Dari perhatian kita di sini adalah tra FFI c konsumsi
dan konsumsi sumber daya. VMI1 akan dikenakan biaya untuk antar-wilayah tra FFI
c (Data Transfer-In dan
Alih-Out Data) dikonsumsi pada saluran yang
menghubungkan untuk S3. Selain itu, VMI1 akan dikenakan biaya untuk tra FFI c
(Data Transfer-In dan Transfer Data-Out) yang dikonsumsi di channel yang
menghubungkan VMI1 ke aplikasi client, sebagai terakhir adalah di luar awan
Amazon. Tidak ada biaya untuk c tra FFI dikonsumsi oleh interaksi terhadap EBS1
sebagai c tra FFI dikonsumsi oleh interaksi antara VMIs dan EBSs gratis. Tidak
ada biaya untuk tra FFI c dikonsumsi oleh interaksi terhadap VMI2 sejak share
zona ketersediaan VMI1 dan VMI2 A. Sumber Daya konsumsi tion dari VMI1 akan
dihitung sebagai jumlah jam yang hal ini dijalankan.
Dalam sia-sia yang sama, biaya untuk VMI2 akan
mempertimbangkan tra konsumsi FFI c dan konsumsi sumber daya. The tra FFI c
dikonsumsi akan ditentukan oleh jumlah Transfer Data-Out dan Transfer Data-In
yang dikirim dan diterima, masing-masing, bersama dua saluran: saluran yang
mengarah ke aplikasi klien dan satu yang mengarah ke VMI3. Tidak ada biaya
untuk tra FFI c dikonsumsi pada saluran yang mengarah ke VMI1 karena dua contoh
berada dalam zona ketersediaan yang sama. Sekali lagi, sumber daya menyebabkan
konsumsi rokoknya akan dihitung sebagai jumlah jam contoh VMI2. Biaya untuk
VMI3 dapat dihitung sama dengan VMI2.
Kita dapat membayangkan bahwa S3 akan dikenakan
biaya untuk traffic fi c dikonsumsi pada saluran yang menghubungkan ke VMI1 dan
pada saluran yang menghubungkan ke aplikasi klien. Selain itu, biaya S3 akan
menjelaskan operasi con- sangkaan dihitung sebagai agregasi dari jumlah operasi
ditempatkan terhadap S3 dengan aplikasi- klien tion dan VMI1. Selain itu, biaya
akan memperhitungkan konsumsi sumber daya pertimbangan (ruang penyimpanan con Diasumsikan)
diukur dalam satuan penyimpanan waktu. Ini akan menjadi dihitung sebagai dampak
agregat dari kegiatan (menempatkan, mendapatkan, menghapus, dll) yang dilakukan
oleh aplikasi klien dan VMI1. Kami mengantisipasi bahwa alat-biaya estimasi
perlu bahasa deskripsi formal untuk mengekspresikan baik deskripsi penyebaran
aplikasi konsumen dan kebijakan harga penyedia. Deskripsi penyebaran akan perlu
untuk memasukkan informasi seperti konstituen sumber daya dan konektivitas
mereka, lokasi geografis sumber daya, jumlah data input dan output, num ber
pengguna untuk mendukung dan sebagainya. Kebijakan harga deskripsi akan perlu
mempertimbangkan particular- yang ities dari provider, seperti untuk Amazon,
tidak ada biaya untuk VMI ke VMI tra FFI c dalam ketersediaan tunggal zona.
Pengembangan sebagai bahasa tersebut disarankan sebagai topik untuk penelitian
lebih lanjut.
10 Penutup
'Bayar hanya untuk apa yang Anda gunakan'
prinsip mendasari model dicas layanan cloud yang digunakan secara luas yang ada
di o ff er. Tidak seperti layanan utilitas tradisional seperti gas dan listrik,
tidak ada layanan metering konsumen terpercaya yang tersedia untuk layanan
cloud, sehingga konsumen tidak punya pilihan selain bergantung pada data
penggunaan yang disediakan oleh penyedia. Uation duduk-ini memotivasi kami
untuk mengusulkan gagasan tentang model akuntansi sumber daya konsumen sentris.
Model akuntansi dikatakan lemah konsumen-sentris jika semua data yang
membutuhkan model untuk menghitung biaya penagihan dapat
tanya pemrograman dari provider. Model ing
pertanggungjawaban dikatakan sangat consumer-centric jika semua data yang
membutuhkan model untuk menghitung biaya penagihan dapat dikumpulkan secara
independen oleh konsumen (atau TTP a); dalam e ff ect, ini berarti bahwa
konsumen (atau TTP a) harus berada dalam posisi untuk menjalankan layanan
pengukuran sendiri. Kami mengevaluasi model akuntansi sumber daya tingkat
infrastruktur penyedia layanan cloud terkemuka dan menemukan bahwa model
akuntansi SDN adalah sangat consumer-centric dan orang-orang dari S3 dan EC2
yang lemah konsumen-sentris.
Penyelidikan kami menunjukkan bahwa karena
deskripsi model akuntansi penyedia layanan kurang jelas dan kelengkapan,
mengumpulkan data metering yang penuh dengan kesulitan-di FFI bahkan untuk
tingkat layanan infrastruktur yang secara konseptual cukup sederhana. Kami
menyarankan cara sistematis menggambarkan model akuntansi sumber daya sehingga
mereka dapat dipahami dan beralasan tentang oleh konsumen. Kami disajikan ide
tentang bagaimana model akuntansi harus dibangun sehingga membuat mereka sangat
konsumen-sentris. Arah untuk penelitian lebih lanjut untuk pengembangan
aplikasi biaya-e berbasis ff efektif awan juga disarankan. Penyedia layanan
dapat belajar dari studi evaluasi kami memeriksa kembali model akuntansi
mereka. Secara khusus, kami merekomendasikan bahwa penyedia awan harus melalui
latihan membangun pengukuran pihak ketiga ser wakil, dan berdasarkan latihan
yang, lakukan perubahan model, menghilangkan potensi sumber ambiguitas dalam
deskripsi model, sehingga bahwa sejauh memungkinkan, konsumen dapat
mengumpulkan dengan kemudahan penggunaan data mereka sendiri yang cocok dengan
data sisi penyedia dengan su FFI efisien presisi.
Catatan akhir
A catatan pada terminologi: 'akuntabilitas'
mengacu pada konsep-konsep seperti tanggung jawab, answerability, trustworthi-
an; tidak menjadi bingung dengan 'sumber daya akuntansi' yang merujuk pada
proses yang bersangkutan dengan menghitung biaya keuangan. Makalah ini menggabungkan dan memperluas
materi yang disampaikan dalam dua makalah konferensi [21,22]. server c S3
disinkronisasi ke Universal Time mengkoordinir dinated (UTC) yang juga dikenal
sebagai Waktu Zulu (Z waktu) dan dalam prakteknya setara dengan Greenwich Berarti
Time (GMT).
Ucapan Terima Kasih
Yang pertama penulis didanai oleh hibah dari
Pemerintah Libya; itu
penulis kedua didanai oleh EPSRC memberikan
KTS-EP / H500332 / 1.
Diterima: 6 Februari 2013 Diterima: 6 Februari
2013
Diterbitkan: 11 Maret 2013
Referensi
1. Elmroth E, Marquez FG, Henriksson D, Ferrera
DP (2009) Akuntansi dan
penagihan untuk infrastruktur cloud federasi.
Dalam: Kedelapan Int'l Conf. di Grid
dan Koperasi Computing, 27-28 Agustus, Lanzhou,
Gansu, Cina, pp
268-275
2. B Bhushan, Tschichholz M, Leray E, Donnelly
W (2001) Federasi
akuntansi: pengisian layanan dan penagihan
dalam bisnis bisnis-ke-
lingkungan hidup. Dalam: Proc 2001 IEEE / IFIP
Int'l Simposium Terpadu
Manajemen Jaringan VII, pp 107-121. IEEE,
Piscataway, NJ, USA
3. de Leastar E, McGibney J (2000) Fleksibel
multi-layanan
sistem akuntansi telekomunikasi. Dalam: Proc.
Int'l Jaringan Conf.
(INC'00). University of Plymouth, School Of
Computing, Komunikasi
Dan Elektronika, Plymouth, UK
4. Sekar V, Maniatis P (2011) Veri fi mampu
sumber daya akuntansi untuk cloud
layanan komputasi. Dalam: Proc. 3 ACM workshop
Cloud computing
lokakarya keamanan (CCSW'11), hlm 21-26.
Association for Computing
Mesin, Inc., New York, NY
5. Skene J, F Raimondi, Emmerich W (2010)
Perjanjian Layanan-level untuk
layanan elektronik. IEEE Trans Software Eng 36
(2): 288-304
6. Molina-Jimenez C, Masak N, Shrivastava S
(2008) Pada kelayakan
bilateral setuju akuntansi konsumsi sumber
daya. Dalam: 1st Int'l
Lokakarya memungkinkan ekosistem bisnis layanan
(ESBE08), Sydney,
Australia. pp 170-283
7. Wang H, Jing Q, R Chen, Dia B, Qian Z, Zhou
L (2010) sistem terdistribusi
memenuhi ekonomi: Pricing di awan. Dalam: Proc.
2 USENIX workshop
topik panas di komputasi awan (HotCloud'10).
USENIX Association,
Berkeley, CA 94710
8. den Bossche RV, Vanmechelen K, Broeckhove J
(2010) Biaya-optimal
penjadwalan in hybrid IAAS awan untuk batas
waktu dibatasi beban kerja. Dalam:
Proc IEEE 3 Int'l Conf. pada komputasi awan
(Cloud'10), hlm 228-235. IEEE
Computer Society, Los Alamitos, CA
9. Suleiman B, Sakr S, Je ff ery R, Liu A
(2011) Pada memahami
ekonomi dan elastisitas tantangan penggelaran
aplikasi bisnis
pada infrastruktur cloud publik. J Internet
Serv Appl 3 (2): pp 173-193.
doi: 10,1007 / s13174-011-0050-y
10. Deelman E, G Singh, Livny M, Berriman B,
Baik J (2008) Biaya melakukan
ilmu di atas awan: Contoh montase. Dalam: Proc.
Int'l Conf. pada tinggi
Kinerja Komputasi, Networking, Penyimpanan dan
Analisis (SC'08). IEEE,
Piscataway, NJ, USA
11. Palankar M, Iamnitchi A, Ripeanu M,
Garfinkel S (2008) Amazon S3 untuk
grid ilmu: solusi yang layak? Dalam: Intl
Workshop Data-Aware
Distributed Computing (DADC'08), Jun 24,
Boston, Amerika Serikat, pp 55-64
12. Amazon (2006) Amazon layanan penyimpanan
sederhana. panduan pengembang, API
versi 2006/03/01. [On Line]. Tersedia:
aws.amazon.com/
dokumentasi / S3 /
13. Murty J (2008) Pemrograman Amazon Web
Services. O'Reilly. ISBN-10:
0596515812, O'Reilly Media, Sebastopol, CA
95472
14. Nirvanix (2012) jaringan penyimpanan
Nirvanix awan. [On Line]. Tersedia www.
nirvanix.com
15. Amazon (2011) Amazon Elastic Compute Cloud
(EC2 amazon). [On Line]
Tersedia: aws.amazon.com/ec2/
16. Amazon EC2 harga (2011). [On Line].
Tersedia aws.amazon.com/ec2/
harga
17. Amazon EC2 faqs (2011). [On Line].
Aws.amazon.com/ec2/faqs Tersedia
18. Amazon Elastic Compute Cloud panduan
pengguna (api versi 2011-02-28)
(2011). [On Line].
Docs.amazonwebservices.com/AWSEC2/latest/ Tersedia
UserGuide /
19. RightScale (2011) manajemen server
Rightscale. [On Line]. Tersedia
Manajemen
support.rightscale.com/12-Guides/Lifecycle
20. Amazon (2012) karya Bagaimana aws harga.
[On Line]. Tersedia http: //
calculator.s3.amazonaws.com/calc5.html
21. Mihoob A, Molina-Jimenez C, Shrivastava S
(2010) Sebuah kasus untuk
Model akuntansi sumber daya konsumen-sentris.
Dalam: Proc. IEEE 3rd Int'l Conf. pada Cloud Computing (Cloud'10), IEEE
Computer Society, California, pp 506-512
22. Mihoob A, Molina-Jimenez C, Shrivastava S
sumber daya side (2011) Konsumen akuntansi di awan. Dalam: Proc. 11 IFIP WG
6.11 Conf. pada tanggal e-Business, e-Services, dan e-Society (I3E 2011), IFIP
AICT 353, Springer, Heidelberg. pp 58-72 doi: 10,1186 / 1869-0238-4-8 Mengutip
artikel ini sebagai: Mihoob et al .: sumber daya konsumen-sentris akuntansi di
awan. Journal of Layanan Internet dan Aplikasi 2013 4: 8.Kirim naskah Anda ke
jurnal dan memperoleh manfaat dari:
7 pengajuan online yang nyaman
7 ketat peer review
7 publikasi Segera pada penerimaan
7 Akses terbuka: artikel tersedia secara online
bebas
7 visibilitas tinggi dalam lapangan
7 Mempertahankan hak cipta untuk artikel Anda
Kirim naskah Anda berikutnya di 7
springeropen.com
