Sebuah NetApp Teknis Buku Harian

Saya tidak bisa mengatakan saya pernah mencoba untuk mengatur password root kosong, dan tidak bisa mengatakan saya akan merekomendasikan hal itu baik. Jika Anda menggunakan "ndmpcopy" Anda dapat menentukan sumber dan tujuan dengan kredensial "-sa username: password" dan "username-da: password".

Terbaik adalah untuk memulai dalam industri. Sebagian besar keterampilan saya datang dari yang otodidak dan bekerja di B2net. Mungkin menemukan vendor penyimpanan atau reseller di wilayah Anda dan melihat tentang mendapatkan beberapa pengalaman kerja.

Saya selalu menemukan mempelajari sulit jika saya tidak punya proyek untuk bekerja menuju, sehingga membaca buku dan mempelajari manual mungkin bukan cara terbaik untuk belajar dengan benar. Lagi pula, itu sangat membosankan melakukan itu!

Hi Scott, B2net pasti bisa memberikan layanan itu untuk Anda, kita tidak hanya memiliki meja 24/7 dukungan yang terlatih dalam semua produk NetApp, tetapi juga sebuah tim insinyur yang sangat terampil dan berbakat. Jika Anda bertanya tentang konsultan independen, aku takut aku benar-benar tidak mendapatkan paparan mereka seperti yang kita memiliki beberapa industri terkemuka keterampilan internal dan jarang perlu terlibat dalam pihak ke-3. Saya akan senang untuk mengatur seseorang untuk menghubungi Anda untuk membicarakan kemungkinan ad-hoc dukungan lebih lanjut seperti itu tentu sesuatu yang dapat kita tawarkan.

Maksudmu AutoSupport? Ya, Anda dapat melakukan hal ini baik dari FilerView atau dari CLI. Dari CLI hanya melakukan ...

pilihan autosupport.doit "string teks di sini"

... Dan ganti "string teks di sini" dengan apa pun pesan yang ingin NetApp untuk bereaksi, biasanya sejumlah kasus.

Hi Ron,

Apakah Anda memiliki (atau apakah Anda memiliki) setiap klon Lun di masa lalu? Mungkin ini telah menjadi terkunci dalam snapshot dan Anda sudah sejak dihapus klon Lun tapi clone masih Lun telah terkunci. Periksa snapshot dari volume dan melihat apakah ada terkunci. Jika Anda menghapus Lun, apakah ada hal lain di volume? Jika Anda secara offline volume, Anda pasti akan menghapus semua link ke Lun. Kemudian Anda hanya bisa menghapus volume dan kembali membuat itu.

Untuk mematikan auto disk yang menetapkan, lakukan hal berikut ...

pilihan disk.auto_assign off

dan kemudian un-sendiri mereka disk lagi. Anda harus baik untuk pergi kemudian!

Hi Kurt,

Masalah ketika Anda memiliki agregat penuh adalah bahwa ini mempengaruhi menulis sebagai isu pertama. Antrian Biasanya WAFL sampai menulis ke garis di semua disk dan akan mencoba untuk melakukan hal ini dengan sama besar garis mungkin karena cara optimal untuk menulis keduanya, dan untuk membaca kemudian. Dengan agregat pada 100%, ada sedikit ruang untuk menulis garis-garis besar, sehingga harus istirahat ini menulis menjadi potongan lebih kecil dan menulis ke dalam sejumlah kecil ruang kosong yang tersedia. Ini membutuhkan menulis lagi, tetapi yang lebih penting ia memiliki dampak besar pada kali dibaca. Berbunyi sekarang perlu untuk melakukan gerakan spindle lebih fisik untuk melakukan read-aheads atau bahkan hanya membaca sekuensial sederhana yang kini diletakkan di poros bukan di urutan ketat bagus.

Menjalankan agregat Anda ke 100% tidak hanya mempengaruhi kinerja menulis langsung, tetapi terus-menerus akan mempengaruhi performa membaca untuk setiap data yang ditulis dalam skala waktu yang agregat sudah dekat penuh, atau penuh. Anda perlu mengurangi penggunaan agregat Anda (turun menjadi kurang dari 80% dianjurkan) dan kemudian mengalokasikan volume untuk mendistribusikan data di gelondongan dengan cara yang lebih tertib lagi. Ini sangat akan meningkatkan performa membaca ke depan, dan ruang bebas akan memungkinkan menulis kinerja satu lagi tampil di kecepatan yang optimal.

Dengan agregat penuh 100%, Anda seringkali tidak melihat masalah harddisk pemanfaatan kinerja, tetapi Anda dapat melihat CPU yang tinggi dan Anda dapat melihat "CP ty" (Konsistensi Jenis Point) butuh waktu lama untuk flush ke disk. Anda bisa melihat ini dari "sysstat-u 1". Hal ini sangat tergantung pada model sistem dan jenis data yang Anda tulis, tapi aturan yang sangat kasar praktis adalah bahwa jika CP adalah mengambil lebih dari mengatakan 3-4 detik, itu bekerja lebih keras dari yang seharusnya dilakukan. Tapi seperti saya katakan, jika Anda memiliki agregat penuh 100%, ada kerja jangka pendek perangkat lunak kecil yang dapat Anda lakukan untuk mengatasi masalah, memperbaiki sederhana, disk lebih banyak atau sedikit data. Jadi membeli beberapa spindle lebih dan menambahkannya ke agregat, kemudian mengalokasikan kembali. Atau menghapus beberapa data / foto dan membebaskan beberapa ruang pada disk dan kemudian mengalokasikan kembali.

Sepertinya Anda memiliki sejumlah besar disk hilang atau gagal dari lingkungan. Ini perlu diperbaiki sebelum Anda dapat membawa agregat kembali online lagi. Anda perlu memeriksa bahwa disk tersambung dengan benar. Cara terbaik untuk mencapai ini mungkin untuk mematikan sistem dan memastikan semua kabel terhubung secara penuh dan aman, dan bahwa semua disk tersambung dengan benar. Mudah-mudahan sesuatu seperti kabel longgar telah menyebabkan filer gagal disk ini bukan suatu data aktual atau kegagalan mekanis dari semua disk. Periksa semua konektivitas yang pertama, maka Anda mungkin dapat unfail disk tersebut jika tidak ada yang benar-benar salah dengan mereka.

Namun jika disk sepenuhnya gagal, maka saya takut Anda bisa berada di cukup situasi.

Saya akan sangat menyarankan Anda menghubungi Dukungan NetApp Global sebagai mereka akan dapat memandu Anda melalui proses pemeriksaan disk ini dan jika mungkin memperbaiki agregat. Ini mungkin sebuah bug yang dikenal dan mudah memperbaikinya, tetapi mereka berada dalam posisi terbaik untuk mendiagnosa ini.

Hi Kurt,

Saya akan memberikan respon yang cepat, meskipun terdengar seperti Anda memiliki hal-hal diurutkan sekarang.

Jika Anda ingin menggunakan SnapManager for Exchange, maka Anda benar-benar memiliki 2 cara yang berbeda untuk menyajikan penyimpanan ke VM Exchange.

1) Hubungkan kepada mereka dengan menggunakan perangkat lunak iSCSI inisiator dalam VM
2) Hubungkan ke mereka menggunakan RDMS pada tingkat ESX dan menyajikan Lun baku ke VM. Hal ini dapat dilakukan baik menggunakan FCP atau iSCSI.

Keuntungan utama dari opsi 1 adalah granularity kontrol. Admin Exchange tidak juga perlu menjadi admin VMware untuk mengelola dan mengendalikan penyimpanan nya. Bisa dibilang setiap orang harus memiliki beberapa pengetahuan VMware sekalipun. The downside ke opsi 1 adalah bahwa jika Anda memiliki banyak VMs membutuhkan penyimpanan dengan cara ini, itu akan menjadi inisiator software independen diinstal untuk semua orang, dan ini memiliki manajemen dan overhead CPU.

Keuntungan dari opsi 2 adalah bahwa Anda memusatkan konektivitas penyimpanan. Terlepas dari penggunaan itu selalu dilakukan pada tingkat VMware, ini dapat memberikan keamanan yang lebih baik dan visibilitas yang menggunakan apa penyimpanan. Keuntungan menggunakan iSCSI pada tingkat host adalah bahwa hanya satu contoh dari inisiator perangkat lunak. Dengan FCP ini menghilang sama sekali. Kelemahan utama dari opsi 2 adalah kebalikan dari opsi 1, admin Exchange tidak mendapatkan kontrol langsung dari penyimpanan-nya, namun dengan SnapDrive Anda masih mendapatkan kontrol cukup baik, Anda masih bisa clone, tumbuh, snapshot dan sebagainya dari dalam SnapDrive.

Menyajikan penyimpanan untuk datastore maka ukiran VMDK adalah mungkin kasus terburuk karena Anda tidak mendapatkan SnapDrive atau integrasi SnapManager dari Exchange, tapi Anda masih memiliki overhead menghubungkan dari VMware. Saya pikir mungkin saja salah ketik dalam pertanyaan Anda seperti yang terlihat seperti Anda memutuskan antara RDM dari inisiator ESX dan iSCSI dalam VM. Favorit pribadi saya menggunakan RDMS walaupun mungkin ada peringatan tambahan atau perubahan jika Anda juga melakukan DR. VMware SRM penawaran baik dengan RDMS bagaimanapun, tetapi tidak bekerja sama sekali dengan inisiator iSCSI dalam VM.

Harap Anda memiliki semua hal sudah diurutkan Namun!

Hi Kurt,

Jika Anda memiliki sebuah cluster, saya akan melihat untuk menempatkan SQL DB pada satu node, dan DB Mail yang ada di node lainnya. Log kemudian duduk pada sistem yang berlawanan lagi. Ini benar-benar membantu untuk menyeimbangkan beban di sebuah cluster, memberi Anda spindle lebih untuk menggunakan dan memberikan tingkat pemisahan fisik. Hal ini juga membantu Anda melakukan beberapa tingkat pengendalian kerusakan dengan sistem dipisahkan seperti ini. Namun saya tidak akan memiliki sistem yang didedikasikan untuk SQL, dan yang lain untuk Exchange, Anda ingin menyeimbangkan hal-hal seperti kayu keluar. Ini akan memberi Anda spindle lebih untuk satu aplikasi, dan Anda masih bisa menerapkan tingkat kontrol.

Juga melihat Penyimpanan IO Kontrol dari sisi VMware hal (cara yang bagus untuk mengontrol IO jika Anda telah mengalami gangguan mesin), dan juga melihat menempatkan prioritas yang berbeda pada volume NetApp. Anda dapat mengatur ini dari sangat rendah, rendah, sedang, tinggi dan sangat tinggi. Ini bekerja dalam cara yang mirip dengan saham VMware, tetapi Anda menempatkan mereka pada tingkat volume dan memiliki beberapa tingkat kontrol atas IO dan kinerja yang setiap volume akan disampaikan. Sebagai contoh Anda mungkin ingin membatasi pengguna CIFS mendukung database SQL. Ini mungkin bahwa segala sesuatu tetap pada media (default), tetapi Anda meletakkan DB Mail sangat tinggi untuk memberikan bagian yang lebih baik sumber daya.

Terima kasih atas umpan balik, itu hanya rasa malu saya tidak mendapatkan lebih banyak waktu untuk melakukan topik lagi!

Bila Anda mengaktifkan prioritas, ia menetapkan default (sedang) kebijakan di semua volume, sehingga Anda tidak perlu melakukannya secara individual. Anda akan perlu untuk mengatur perbedaan individual ini sebagai diperlukan namun.

Prioritas dapat membantu sistem yang berjuang untuk bersaing dengan hal-hal seperti SnapMirror karena memberikan prioritas di atas tugas-tugas sistem. Seperti halnya jenis alat berbagi sumber daya (sama seperti saya katakan saya pelanggan VMware) membatasi sumber daya pada sistem yang sibuk tentu saja akan mempengaruhi hal. Itu akan membuat situasi yang buruk lebih baik untuk volume yang Anda berikan prioritas, tapi itu akan membuatnya lebih buruk untuk semua volume lainnya. Sebuah sistem di bawah beban berat sudah yang mengalami masalah kinerja tidak kandidat terbaik untuk saham sumber daya atau batas prioritas. Saya akan merekomendasikan Anda mengatasi masalah performa pertama atau mulai mencari untuk membatasi beban dari sisi aplikasi sebelum menempatkan prioritas di semua volume.

Ingat juga bahwa prioritas hanya datang ke dalam bermain ketika ada sumber daya yang minta. Jadi jika misalnya Anda ingin memberikan lebih banyak sumber daya ke SQL dan Exchange, dan satu-satunya sumber informasi lainnya pada sistem yang ringan digunakan saham CIFS, Anda mungkin akan mendapatkan sedikit manfaat sebagai sedikit IO yang dihasilkan dari saham CIFS. Mengutamakan semua untuk SQL dan Bursa masih akan menghasilkan kendala mereka dengan eachother.

Hi Michael, maaf atas keterlambatan dalam mendapatkan kembali kepada Anda. Anda dapat mencoba untuk melakukan resync SnapMirror, namun kemungkinan besar bahwa ini sekarang mungkin memerlukan dasar baru. Selain itu jika VSM tidak dapat menghapus snap tujuan, maka kemungkinan bahwa klon fleksibel masih terkunci ini telah entah bagaimana. Proses pemisahan dapat mengambil beberapa waktu untuk menyelesaikan, sehingga Anda mungkin telah mencoba untuk melakukan hal ini terlalu cepat setelah memulai perpecahan.

Sayangnya ketika SnapMirror macet atau bingung, satu-satunya pilihan yang nyata adalah data dasar kecuali beberapa snapshot yang sama masih ada. Aku sudah dalam situasi canggung di mana aku harus kembali tujuan awal karena foto tidak dihapus untuk satu alasan atau lainnya.

Mohon maaf untuk hilang tanggapan Anda!

Dapatkah Anda memberi saya gambaran yang lebih luas dari konfigurasi volume / Lun. Apakah volume dalam pertanyaan FlexClone, atau itu sedang FlexCloned? Jika tidak, telah operasi Lun klon pun telah dilakukan di atasnya, baik secara manual atau dari pekerjaan SnapManager? Bila Anda menunjukkan foto-foto untuk volume, apa itu menunjukkan? Setiap snapshot tertentu menunjukkan sebagai terkunci atau sibuk? ini Lun dipetakan saat ini?

Lun klon membuat tiruan dari Lun dalam volume yang sama seperti aslinya. Ini berarti bahwa jika operasi snapshot berikutnya terjadi setelah clone dibuat, ini benar-benar mengunci klon Lun yang kemudian direferensikan dalam snapshot sehingga tidak dapat dihapus. Hal ini dapat menyebabkan beberapa jadwal dan tantangan administrasi.

FlexClone jauh lebih fleksibel dalam hal ini karena menciptakan tiruan dari snapshot tertentu dari seluruh volume. Meskipun ini akan mengunci snapshot individu, itu tidak mempengaruhi operasi snapshot masa depan, dan mekanisme penguncian hanya mempengaruhi tugas-tugas rutin normal jika FlexClone dipertahankan lebih lama dari periode snapshot retensi normal.

FlexClone adalah teknologi ramah jauh lebih dinamis dan admin dan pasti pendekatan yang direkomendasikan. Dibutuhkan banyak kerumitan bahwa klon Lun sering dapat menyebabkan.

Tidak ada yang Kranz terlalu banyak di sekitar Aku akan memberitahu Tom kali aku melihatnya!

Sepertinya Anda telah memukul bug yang dikenal di VSC. Hanya solusi nyata adalah pendekatan scripted untuk memperbaiki penamaan (yang tampaknya bekerja untuk beberapa orang), atau menunggu NetApp untuk memperbaiki kode di VSC untuk mencegah hal ini terjadi!

Dan tidak ada snapshot terhadap volume berisi Lun? Apakah Lun dipetakan ke setiap inisiator? Apakah volume host setiap Luns lain? Dari perintah statistik atau statistik lun perintah, apakah Anda melihat aktivitas apapun akan Lun ini?