Pertanyaan yang sering diajukan Service Fabric
Ada banyak pertanyaan umum yang sering diajukan tentang apa yang dapat dilakukan Service Fabric dan bagaimana seharusnya digunakan. Dokumen ini mencakup banyak pertanyaan umum dan jawabannya.
Catatan
Sebaiknya Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Untuk memulai, lihat Menginstal Azure PowerShell. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.
Penyiapan dan manajemen kluster
Bagaimana cara mengembalikan sertifikat kluster Service Fabric saya?
Mengembalikan peningkatan apa pun ke aplikasi Anda memerlukan deteksi kegagalan kesehatan sebelum kuorum kluster Service Fabric Anda melakukan perubahan; perubahan yang diterapkan hanya dapat digulirkan ke depan. Insinyur eskalasi melalui Layanan Dukungan Pelanggan, mungkin diperlukan untuk memulihkan kluster Anda, jika sesuatu memperkenalkan perubahan sertifikat yang melanggar yang tidak dimonitor. Peningkatan aplikasi Service Fabric menerapkan parameter peningkatan aplikasi dan memberikan janji peningkatan downtime nol. Mengikuti mode pemantauan peningkatan aplikasi yang disarankan, kemajuan otomatis melalui domain pembaruan didasarkan pada pemeriksaan kesehatan yang lewat, bergulir kembali secara otomatis jika memperbarui layanan default gagal.
Jika kluster Anda masih menggunakan properti Certificate Thumbprint klasik di templat Resource Manager Anda, kami sarankan Anda Mengubah kluster dari thumbprint sertifikat ke nama umum, untuk menerapkan fitur manajemen rahasia modern.
Bisakah saya membuat kluster yang mencakup beberapa wilayah Azure atau pusat data saya sendiri?
Ya.
Teknologi pengelompokan Service Fabric inti dapat digunakan untuk menggabungkan komputer yang berjalan di mana saja di dunia, selama mereka memiliki konektivitas jaringan satu sama lain. Namun, membangun dan menjalankan kluster seperti itu bisa rumit.
Jika Anda tertarik dengan skenario ini, kami mendorong Anda untuk menghubungi baik melalui Daftar Masalah Service Fabric GitHub atau melalui perwakilan dukungan Anda untuk mendapatkan panduan tambahan. Tim Service Fabric berupaya memberikan kejelasan, bimbingan, dan rekomendasi tambahan untuk skenario ini.
Beberapa hal yang perlu dipertimbangkan:
- Sumber daya kluster Service Fabric di Azure adalah regional saat ini, seperti halnya set skala komputer virtual yang dibangun oleh kluster. Ini berarti bahwa jika terjadi kegagalan regional, Anda mungkin kehilangan kemampuan untuk mengelola kluster melalui Azure Resource Manager atau portal Microsoft Azure. Ini dapat terjadi meskipun kluster tetap berjalan dan Anda akan dapat berinteraksi dengannya secara langsung. Selain itu, Azure saat ini tidak menawarkan kemampuan untuk memiliki satu jaringan virtual yang dapat digunakan di seluruh wilayah. Ini berarti bahwa kluster multi-wilayah di Azure memerlukan Alamat IP Publik untuk setiap VM dalam set skala komputer virtual atau Azure VPN Gateways. Pilihan jaringan ini memiliki dampak yang berbeda pada biaya, performa, dan untuk beberapa desain aplikasi gelar, sehingga analisis dan perencanaan yang cermat diperlukan sebelum berdiri lingkungan seperti itu.
- Pemeliharaan, manajemen, dan pemantauan komputer ini dapat menjadi rumit, terutama ketika membentang di seluruh jenis lingkungan, seperti antara penyedia cloud yang berbeda atau antara sumber daya lokal dan Azure. Perawatan harus dilakukan untuk memastikan bahwa peningkatan, pemantauan, manajemen, dan diagnostik dipahami untuk kluster dan aplikasi sebelum menjalankan beban kerja produksi di lingkungan tersebut. Jika Anda sudah mengalami pemecahan masalah ini di Azure atau dalam pusat data Anda sendiri, kemungkinan solusi yang sama tersebut dapat diterapkan saat membangun atau menjalankan kluster Service Fabric Anda.
Apakah node Service Fabric secara otomatis menerima pembaruan OS?
Anda dapat menggunakan fitur Virtual Machine Scale Set Automatic OS Image Update Generally Available hari ini.
Untuk kluster yang TIDAK dijalankan di Azure, kami telah menyediakan aplikasi untuk menambal sistem operasi di bawah node Service Fabric Anda.
Dapatkah saya menggunakan set skala komputer virtual besar di kluster SF saya?
Jawaban singkat - Tidak.
Jawaban Panjang - Meskipun set skala komputer virtual besar memungkinkan Anda untuk menskalakan skala komputer virtual yang diatur hingga 1000 instans VM, itu melakukannya dengan menggunakan Grup Penempatan (PGs). Domain kesalahan (FD) dan domain peningkatan (UD) hanya konsisten dalam grup penempatan Service Fabric menggunakan FD dan UD untuk membuat keputusan penempatan replika layanan / instans Layanan Anda. Karena FD dan UL hanya sebanding dalam grup penempatan, SF tidak dapat menggunakannya. Misalnya, Jika VM1 di PG1 memiliki topologi FD=0 dan VM9 di PG2 memiliki topologi FD=4, itu tidak berarti bahwa VM1 dan VM2 berada di dua Rak Perangkat Keras yang berbeda, oleh karena itu SF tidak dapat menggunakan nilai FD dalam hal ini untuk membuat keputusan penempatan.
Ada masalah lain dengan set skala komputer virtual besar saat ini, seperti kurangnya dukungan keseimbangan beban level-4. Lihat untuk detail tentang Set skala besar
Berapa ukuran minimal kluster Service Fabric? Mengapa tidak bisa lebih kecil?
Ukuran minimal yang didukung untuk kluster Service Fabric yang menjalankan beban kerja produksi adalah lima node. Untuk skenario dev, kami mendukung satu node (dioptimalkan untuk pengalaman pengembangan cepat di Visual Studio) dan lima kluster node.
Kami memerlukan kluster produksi untuk memiliki setidaknya lima node karena tiga alasan berikut:
- Bahkan ketika tidak ada layanan pengguna yang berjalan, kluster Service Fabric menjalankan serangkaian layanan sistem yang canggih, termasuk layanan penamaan dan layanan manajer failover. Layanan sistem ini sangat penting bagi kluster untuk tetap beroperasi.
- Kami selalu menempatkan satu replika layanan per node, jadi ukuran kluster adalah batas atas untuk jumlah replika layanan (sebenarnya partisi) dapat memiliki.
- Karena peningkatan kluster akan menurunkan setidaknya satu node, kami ingin memiliki penyangga setidaknya satu node, oleh karena itu, kami ingin kluster produksi memiliki setidaknya dua node selain yang paling minimal. Paling minimal adalah ukuran kuorum layanan sistem seperti yang dijelaskan di bawah ini.
Kami ingin kluster tersedia dalam menghadapi kegagalan simultan dari dua node. Agar kluster Service Fabric tersedia, layanan sistem harus tersedia. Layanan sistem yang canggih seperti layanan penamaan dan layanan manajer failover, yang melacak layanan apa yang telah digunakan ke kluster dan di mana mereka saat ini dihosting, tergantung konsistensi yang kuat. Konsistensi yang kuat itu, pada gilirannya, tergantung pada kemampuan untuk memperoleh kuorum untuk setiap pembaruan yang diberikan untuk keadaan layanan tersebut, di mana kuorum mewakili sebagian besar replika (N/ 2 +1) untuk layanan tertentu. Dengan demikian, jika kita ingin tangguh terhadap hilangnya dua simpul secara bersamaan (kehilangan dua replika serentak dari layanan sistem), kita harus memiliki ClusterSize - QuorumSize >= 2, yang memaksa ukuran minimum menjadi lima.
Perhatikan, dalam argumen di atas kami telah mengasumsikan bahwa setiap simpul memiliki replika layanan sistem; dengan demikian, ukuran kuorum dihitung berdasarkan jumlah simpul dalam kluster. Namun, dengan mengubah TargetReplicaSetSize kita bisa membuat ukuran kuorum kurang dari (N / 2 + 1) yang mungkin memberikan kesan bahwa kita bisa memiliki kluster yang lebih kecil dari 5 node dan masih memiliki 2 node tambahan di atas ukuran kuorum. Misalnya, dalam kluster node 4, jika kita menetapkan TargetReplicaSetSize ke 3, ukuran kuorum berdasarkan TargetReplicaSetSize adalah (3/2 + 1) atau 2, dengan demikian kita memiliki ClusterSize - QuorumSize = 4-2 >= 2. Namun, kami tidak dapat menjamin bahwa layanan sistem akan berada di atau di atas kuorum jika kami kehilangan sepasang node secara bersamaan, bisa jadi dua node yang kami kehilangan menghosting dua replika, sehingga layanan sistem mengalami kehilangan kuorum (hanya memiliki satu replika tersisa) dan akan menjadi tidak tersedia.
Dengan latar belakang itu, mari kita periksa beberapa konfigurasi kluster yang mungkin:
Satu node: opsi ini tidak memberikan ketersediaan tinggi karena hilangnya node tunggal karena alasan apa pun berarti hilangnya seluruh kluster.
Dua node: kuorum untuk layanan yang diterapkan di dua node (N = 2) adalah 2 (2/2 + 1 = 2). Ketika satu replika hilang, tidak mungkin untuk membuat kuorum. Karena melakukan peningkatan layanan mengharuskan untuk sementara menurunkan replika, ini bukan konfigurasi yang berguna.
Tiga node: dengan tiga node (N=3), persyaratan untuk membuat kuorum masih dua node (3/2 + 1 = 2). Ini berarti bahwa Anda dapat kehilangan node individu dan masih mempertahankan kuorum, tetapi kegagalan simultan dari dua node akan mendorong layanan sistem menjadi kehilangan kuorum dan akan menyebabkan kluster menjadi tidak tersedia.
Empat node: dengan empat node (N=4), persyaratan untuk membuat kuorum adalah tiga node (4/2 + 1 = 3). Ini berarti bahwa Anda dapat kehilangan node individu dan masih mempertahankan kuorum, tetapi kegagalan simultan dari dua node akan mendorong layanan sistem menjadi kehilangan kuorum dan akan menyebabkan kluster menjadi tidak tersedia.
Lima node: dengan lima node (N=5), persyaratan untuk membuat kuorum masih tiga node (5/2 + 1 = 3). Ini berarti Bahwa Anda dapat kehilangan dua node pada saat yang sama dan masih mempertahankan kuorum untuk layanan sistem.
Untuk beban kerja produksi, Anda harus tangguh terhadap kegagalan simultan setidaknya dua node (misalnya, satu karena peningkatan kluster, satu karena alasan lain), sehingga diperlukan lima node.
Dapatkah saya menonaktifkan kluster saya di malam hari/akhir pekan untuk menghemat biaya?
Secara umum, tidak. Service Fabric menyimpan status pada disk lokal sementara, yang berarti bahwa jika komputer virtual dipindahkan ke host yang berbeda, data tidak bergerak dengannya. Dalam operasi normal, itu bukan masalah karena simpul baru diperbarui oleh simpul lain. Namun, jika Anda menghentikan semua node dan me-restart nanti, ada kemungkinan signifikan bahwa sebagian besar node dimulai pada host baru dan membuat sistem tidak dapat pulih.
Jika Anda ingin membuat kluster untuk menguji aplikasi Anda sebelum disebarkan, kami sarankan Anda membuat kluster tersebut secara dinamis sebagai bagian dari alur integrasi berkelanjutan/penyebaran berkelanjutan Anda.
Bagaimana cara meningkatkan Sistem Operasi saya (misalnya dari Windows Server 2012 ke Windows Server 2016)?
Saat kami sedang mengerjakan pengalaman yang ditingkatkan, hari ini, Anda bertanggung jawab atas peningkatan. Anda harus meningkatkan citra OS pada komputer virtual kluster satu VM pada satu waktu.
Dapatkah saya mengenkripsi disk data yang terpasang dalam jenis node kluster (set skala komputer virtual)?
Ya. Untuk informasi selengkapnya, lihat Membuat kluster dengan disk data terlampir dan Enkripsi Disk Azure untuk Set Skala Komputer Virtual.
Dapatkah saya menggunakan VM berprioritas rendah dalam jenis node kluster (set skala komputer virtual)?
Tidak. VM berprioritas rendah tidak didukung.
Apa saja direktori dan proses yang perlu saya kecualikan saat menjalankan program anti-virus di kluster saya?
| Direktori Antivirus Dikecualikan |
|---|
| Program Files\Microsoft Service Fabric |
| FabricDataRoot (dari konfigurasi kluster) |
| FabricLogRoot (dari konfigurasi kluster) |
| Antivirus Proses yang dikecualikan |
|---|
| Fabric.exe |
| FabricHost.exe |
| FabricInstallerService.exe |
| FabricSetup.exe |
| FabricDeployer.exe |
| ImageBuilder.exe |
| FabricGateway.exe |
| FabricDCA.exe |
| FabricFAS.exe |
| FabricUOS.exe |
| FabricRM.exe |
| FileStoreService.exe |
Bagaimana aplikasi saya dapat mengautentikasi ke Key Vault untuk mendapatkan rahasia?
Berikut ini adalah sarana bagi aplikasi Anda untuk mendapatkan kredensial untuk mengautentikasi ke Key Vault:
J. Selama pekerjaan build/packing aplikasi, Anda dapat menarik sertifikat ke dalam paket data aplikasi SF, dan menggunakan ini untuk mengautentikasi ke Key Vault. B. Untuk set skala komputer virtual host yang diaktifkan MSI, Anda dapat mengembangkan PowerShell SetupEntryPoint sederhana untuk aplikasi SF Anda untuk mendapatkan token akses dari titik akhir MSI, lalu mengambil rahasia Anda dari Key Vault.
Bisakah saya mentransfer langganan saya ke penyewa Microsoft Entra lain?
Tidak. Saat ini Anda perlu membuat sumber daya kluster Service Fabric baru setelah langganan ditransfer ke penyewa Microsoft Entra yang berbeda.
Dapatkah saya memindahkan/memigrasikan kluster saya di antara penyewa Microsoft Entra?
Tidak. Saat ini Anda perlu membuat sumber daya kluster Service Fabric baru di bawah penyewa baru.
Bisakah saya memindahkan/memigrasikan kluster saya antar langganan?
Tidak. Saat ini Anda perlu membuat sumber daya kluster Service Fabric baru di bawah langganan baru.
Dapatkah saya memindahkan/memigrasikan sumber daya kluster atau kluster saya ke grup sumber daya lain atau mengganti namanya?
Tidak. Saat ini Anda perlu membuat sumber daya kluster Service Fabric baru di bawah grup/nama sumber daya baru.
Desain Aplikasi
Apa cara terbaik untuk mengkueri data di seluruh partisi Koleksi yang Dapat Diandalkan?
Koleksi yang andal biasanya dipartisi untuk memungkinkan skala keluar untuk performa dan throughput yang lebih besar. Itu berarti bahwa negara untuk layanan tertentu dapat tersebar di puluhan atau ratusan komputer. Untuk melakukan operasi di atas kumpulan data lengkap itu, Anda memiliki beberapa opsi:
- Buat layanan yang meminta semua partisi layanan lain untuk menarik data yang diperlukan.
- Buat layanan yang dapat menerima data dari semua partisi layanan lain.
- Dorong data secara berkala dari setiap layanan ke toko eksternal. Pendekatan ini hanya sesuai jika kueri yang Anda lakukan bukan bagian dari logika bisnis inti Anda, karena data toko eksternal akan basi.
- Atau, simpan data yang harus mendukung kueri di semua rekaman secara langsung di penyimpanan data daripada dalam koleksi yang dapat diandalkan. Ini menghilangkan masalah dengan data basi, tetapi tidak memungkinkan keuntungan dari koleksi yang dapat diandalkan untuk dimanfaatkan.
Apa cara terbaik untuk mengkueri data di seluruh aktor saya?
Aktor dirancang untuk menjadi unit status dan komputasi independen, sehingga tidak disarankan untuk melakukan kueri luas status aktor saat runtime. Jika Anda memiliki kebutuhan untuk meminta di seluruh kumpulan status aktor lengkap, Anda harus mempertimbangkan:
- Mengganti layanan aktor Anda dengan layanan yang dapat diandalkan, sehingga jumlah permintaan jaringan untuk mengumpulkan semua data dari jumlah aktor ke jumlah partisi dalam layanan Anda.
- Merancang aktor Anda untuk secara berkala mendorong statusnya ke toko eksternal untuk kueri yang lebih mudah. Seperti di atas, pendekatan ini hanya layak jika kueri yang Anda lakukan tidak diperlukan untuk perilaku runtime Anda.
Berapa banyak data yang dapat saya simpan di Koleksi yang Dapat Diandalkan?
Layanan yang andal biasanya dipartisi, sehingga jumlah yang dapat Anda simpan hanya dibatasi oleh jumlah komputer yang Anda miliki di kluster, dan jumlah memori yang tersedia pada komputer-komputer tersebut.
Sebagai contoh, misalkan Anda memiliki koleksi yang dapat diandalkan dalam layanan dengan 100 partisi dan 3 replika, menyimpan objek yang berukuran rata-rata 1 kb. Sekarang misalkan Anda memiliki kluster komputer 10 dengan memori 16gb per komputer. Untuk kesederhanaan dan menjadi konservatif, asumsikan bahwa sistem operasi dan layanan sistem, runtime Service Fabric, dan layanan Anda mengkonsumsi 6gb itu, meninggalkan 10gb tersedia per komputer, atau 100 gb untuk kluster.
Perlu diingat bahwa setiap objek harus disimpan tiga kali (satu replika primer dan dua), Anda akan memiliki memori yang cukup untuk sekitar 35 juta objek dalam koleksi Anda saat beroperasi dengan kapasitas penuh. Namun, kami sarankan untuk tahan terhadap hilangnya domain kegagalan secara bersamaan dan domain peningkatan, yang mewakili sekitar 1/3 kapasitas, dan akan mengurangi jumlahnya menjadi sekitar 23 juta.
Perhitungan ini juga mengasumsikan:
Bahwa distribusi data di seluruh partisi kira-kira seragam atau Anda melaporkan metrik beban ke Manajer Sumber Daya Kluster. Secara default, Service Fabric memuat keseimbangan berdasarkan jumlah replika. Dalam contoh sebelumnya, yang akan menempatkan 10 replika utama dan 20 replika sekunder pada setiap node di kluster. Yang bekerja dengan baik untuk beban yang merata di seluruh partisi. Jika beban bahkan tidak, Anda harus melaporkan beban sehingga Resource Manager dapat mengemas replika yang lebih kecil bersama-sama dan memungkinkan replika yang lebih besar untuk mengonsumsi lebih banyak memori pada node individual.
Bahwa layanan yang dapat diandalkan yang dimaksud adalah satu-satunya negara penyimpanan dalam kluster. Karena Anda dapat menerapkan beberapa layanan ke kluster, Anda harus memperhatikan sumber daya yang masing-masing perlu dijalankan dan dikelola negaranya.
Bahwa kluster itu sendiri tidak tumbuh atau menyusut. Jika Anda menambahkan lebih banyak komputer, Service Fabric akan menyeimbangkan kembali replika Anda untuk memanfaatkan kapasitas tambahan sampai jumlah mesin melampaui jumlah partisi dalam layanan Anda, karena replika individual tidak dapat menjangkau mesin. Sebaliknya, jika Anda mengurangi ukuran kluster dengan melepas komputer, replika Anda dikemas lebih ketat dan memiliki kapasitas keseluruhan yang lebih sedikit.
Berapa banyak data yang dapat saya simpan dalam aktor?
Seperti halnya layanan yang andal, jumlah data yang dapat Anda simpan dalam layanan aktor hanya dibatasi oleh total ruang disk dan memori yang tersedia di seluruh node di kluster Anda. Namun, aktor individu paling efektif ketika mereka digunakan untuk merangkum sejumlah kecil logika negara dan bisnis terkait. Sebagai aturan umum, seorang aktor individu harus memiliki keadaan yang diukur dalam kilobyte.
Di mana Penyedia Azure Service Fabric Resource menyimpan data pelanggan?
Penyedia Sumber Daya Azure Service Fabric tidak memindahkan atau menyimpan data pelanggan keluar dari wilayah tempat data tersebut disebarkan.
Pertanyaan lain
Bagaimana Service Fabric berhubungan dengan kontainer?
Kontainer menawarkan cara sederhana untuk mengemas layanan dan ketergantungan mereka sehingga mereka berjalan secara konsisten di semua lingkungan dan dapat beroperasi dengan cara yang terisolasi pada satu komputer. Service Fabric menawarkan cara untuk menyebarkan dan mengelola layanan, termasuk layanan yang telah dikemas dalam kontainer.
Apakah Anda berencana untuk open-source Service Fabric?
Kami memiliki bagian terbuka dari Service Fabric (kerangka kerja layanan yang andal, kerangka kerja aktor yang andal, pustaka integrasi inti ASP.NET, Service Fabric Explorer, dan Service Fabric CLI) di GitHub dan menerima kontribusi komunitas untuk proyek-proyek tersebut.
Kami baru-baru ini mengumumkan bahwa kami berencana untuk open-source runtime Service Fabric. Pada titik ini, kami memiliki repo up Service Fabric di GitHub dengan alat build dan pengujian Linux, yang berarti Anda dapat mengkloning repo, membangun Service Fabric untuk Linux, menjalankan tes dasar, membuka masalah, dan mengirimkan permintaan tarik. Kami bekerja keras untuk membuat lingkungan build Windows juga bermigrasi, bersama dengan lingkungan CI yang lengkap.
Ikuti blog Service Fabric untuk detail selengkapnya saat diumumkan.
Langkah berikutnya
Pelajari tentang konsep waktu proses Service Fabric dan praktik terbaik