Konvensi Penamaan IQN


9

Saya telah melihat banyak informasi tentang bagaimana IQN harus diformat, tetapi tidak ada banyak informasi tentang cara membangunnya. Saya agak baru ketika datang ke iSCSI, dan saya membuatnya bekerja, tapi saya bertanya-tanya apakah saya harus membuat hal-hal ini, atau jika ada alasan yang baik untuk mengikuti semacam standar.

Sebagai contoh, beginilah caranya (wikipedia http://en.wikipedia.org/wiki/ISCSI#Addressing ) mengatakan Anda harus memformat IQN.

              Naming     String defined by
 Type  Date    Auth      "example.com" naming authority
+--++-----+ +---------+ +-----------------------------+
|  ||     | |         | |                             |     

iqn.1992-01.com.example:storage:diskarrays-sn-a8675309
iqn.1992-01.com.example
iqn.1992-01.com.example:storage.tape1.sys1.xyz
iqn.1992-01.com.example:storage.disk2.sys1.xyz[10]

Pertanyaan saya khususnya, Mengapa tanggalnya? Bisakah itu apa saja, Apakah itu berarti apa-apa? Apakah ada penegakan di sini? Apakah saya akan pernah mengalami titik di mana memasukkan tanggal yang 'salah' akan menggigit saya?

Apakah contoh domain dibalik (seperti dns) karena suatu alasan? Jika saya memiliki nama domain seperti starkindustries.pri akan terlihat seperti iqn saya:

iqn.2006-05.pri.starkindustries:Linux:array0

Apakah ini tergantung pada DNS? (pengalaman memberi tahu saya bukan, tapi bisa saja gagal dengan cara sublte) Dan jika tergantung pada DNS, apakah saya menggunakan nama host, atau hanya nama domain saya? yaitu Jarvis.starkindustries.pri atau hanya starkindustries.pri?

Juga Jika saya menggunakan alamat IP (yang beberapa menyarankan jika Anda tidak menggunakan DNS yang lebih membingungkan karena berfungsi tanpa DNS) apakah Anda membalikkannya seperti yang Anda lakukan dns? yaitu 10.1.2.0

iqn.2006-05.0.2.1.10:Linux:array0 

Juga, apakah Anda menggunakan alamat host (target iSCSI?) Atau alamat jaringan.

Apakah ada penegakan dari 'string yang didefinisikan oleh "example.com" otoritas penamaan' yaitu apakah ada alasan saya tidak dapat menggunakan blahblahblah vs sesuatu yang bermanfaat? Saya menyadari nama yang berguna lebih deskriptif, tetapi apakah ada alasan teknis untuk ini? Saya juga melakukan lompatan besar keyakinan bahwa saya adalah 'otoritas penamaan'.

Saya kira lebih dari apa pun, saya mengarang banyak hal untuk IQN ini, dan mereka tampaknya berfungsi. Saya hanya ingin tahu setidaknya di mana menemukan beberapa praktik terbaik ketika datang ke generasi aktual dari iqns. Saya hanya mempertimbangkan bahwa suatu hari nanti saya tidak akan menjadi satu-satunya penanggung jawab penyimpanan, jadi saya perlu menurunkan beberapa standar, atau saya akan membuat kekacauan, atau meminta orang lain membuat kekacauan ketika diperlukan blok IQN baru.


Halaman wiki yang Anda referensikan menjelaskan bagian tanggal "date (yyyy-mm) di mana otoritas penamaan mengambil kepemilikan atas domain". Mengapa - itu masuk akal. Artinya apa yang dikatakannya. Seharusnya seperti yang dikatakannya. Jangan gunakan data yang salah. ?
CrackerJack9

Saya otoritas penamaan. Tanggal berapa yang saya gunakan? Ketika saya mengatur server DNS. Kapan nama DNS pertama kali didaftarkan? Kapan Yankees terakhir memenangkan seri dunia?
Steve Butler

Saya tidak tahu tentang yang lain, tetapi alasan bahwa nama domain mundur sangat sederhana: ia beralih dari bagian yang paling tidak spesifik ke yang paling spesifik. Hal yang sama berlaku tentang mengapa format tanggal memiliki tahun pertama, lalu bulan. Ini juga salah satu cara paling umum untuk mengatur ruang nama kode dalam bahasa yang mendukungnya, seperti Java, C #, PHP. Lihat Wikipedia .
Moshe Katz

Saya kira saya mendapatkan alasan mengapa itu bisa terjadi, tetapi sepertinya sangat sewenang-wenang. Tampaknya tidak ada penegakan, hanya pedoman. Pedomannya bagus, tetapi jika saya bisa lolos dengan iqn: host: Target: Lun saya akan.
Steve Butler

Jawaban:


7

Alasan di balik ini dalam RFC 3720 adalah bahwa di atas semua itu, IQN harus unik. Tanggal yang ditulis sebelumnya adalah jaminan yang masuk akal bahwa entitas yang mengendalikan nama domain yang diwakili (dalam bidang penamaan auth) pada saat itu merupakan "otoritas penamaan" yang dapat memastikan keunikan - nama domain berpindah tangan sepanjang waktu dan karena satu-satunya hal unik lainnya yang terjadi adalah ke RHS yang pertama: (yang gratis untuk semua) mungkin sudah ada Linux: array0 atau sesuatu yang serupa imajinatif mengambang di sekitar.

RFC 3720 menggunakan (sering kali lucu) HARUS untuk mendefinisikan tanggal sebagai YYYY-MM dan masuk ke detail yang merusak tentang format dan waktu penggunaan yang tepat, dll. ). Apakah polisi RFC akan mendobrak pintu Anda jika Anda memanggil target Anda iqn.screwyouRFC3720? Apakah akan merusak internet? Tidak.

Ini sama sekali tidak ada hubungannya dengan DNS, DNS hanyalah sistem hierarki yang praktis, didelegasikan, yang telah membawa Anda dari TLD ke satu perangkat, jika Anda mau, jadi ini cara mudah untuk mengidentifikasi pihak-pihak yang bertanggung jawab.

Secara pribadi, saya ingin memastikan bahwa IQN mengatakan sesuatu tentang kapan, siapa, apa, mengapa, dan betapa pentingnya data itu, jadi ketika saya mencari ruang di suatu tempat saya tahu siapa yang harus bertanya.

Suka atau tidak, Anda adalah otoritas penamaan.


Penjelasan yang bagus. Saya menyadari bahwa saya adalah otoritas penamaan. Untungnya / Sayangnya NetApps yang saya gunakan dalam produksi menjadi sangat cerewet tentang tetap menggunakan RFC (sementara kotak uji linux saya tampaknya tidak peduli), bahkan sampai pada titik di mana saya harus menggunakan com / net / org di iqn. Ini membuat frustrasi, terutama karena saya ingin menggunakan lebih banyak penamaan yang berguna dan verbose. yaitu iqn. {Tanggal sewenang-wenang}. {hostname}: {Array} {Lun}. Secara pribadi saya juga lebih suka memilikinya maju daripada mundur. jauh lebih mudah untuk mengingat bahwa host jarvis.starkindustries.pri, memiliki iqn dari iqn.2012-01.jarvis.starkindustries.pri
Steve Butler
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.