Nama yang Berbeda Pada Portal Azure GUI

"Badrequest: Jaringan Virtual Publik-Azure-Timur Tidak Ada" Nama Jaringan Virtual Yang Ditampilkan Di Portal Dapat Salah #Azure #Azureclassic

Hari ini, saya belajar sesuatu yang baru – Nama yang berbeda-beda di Portal Azure GUI. Saya mencoba membantu pelanggan menggunakan beberapa VM dalam Azure Classic yang memiliki dua kartu NIC. Tidak masalah saya katakan, sudah lama sejak saya bekerja dengan Azure Classic. Dari apa yang saya ingat itu cukup lurus ke depan, meskipun itu harus dilakukan melalui PowerShell karena tidak ada opsi GUI di portal untuk menyebarkan dua NIC. Petunjuk dasar dapat ditemukan di sini. https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-multiple-nics/ Namun, setelah membenturkan kepala saya ke dinding selama beberapa jam, saya menemukan informasi ini. https://thelonedba.wordpress.com/2015/07/17/new-azurevm-badrequest-the-virtual-network-foo-does-not-exist

Nama Yang Berbeda Pada Portal Azure GUI

Sepertinya apa yang dikatakan oleh Portal Azure GUI tentang nama jaringan virtual Anda kadang-kadang bisa benar-benar berbeda dari nama sebenarnya yang dikembalikan ketika Anda menjalankan Get-AzureVMNetSite | Pilih Nama. Pada dasarnya, ada nama yang berbeda di Azure Portal GUI. Dan mengapa demikian? Lihat gambar layar di bawah ini. Jaringan Virtual yang saya buat bernama "Publik-Azure-Timur" sebenarnya disebut "Grup Grup Azure Publik Timur". Bagaimana itu terjadi dan mengapa ada nama yang berbeda di Azure Portal GUI di luar pemahaman saya. Seperti yang Anda lihat, usaha saya yang lemah dalam menciptakan mesin virtual gagal. Ini mengatakan "BadRequest: Jaringan virtual Publik-Azure-Timur tidak ada." Saya yakin itu ada hubungannya dengan beberapa langganan yang saya gunakan. Tapi ternyata bug ini di mana ia menampilkan nama yang berbeda di Azure Portal GUI. Mengapa sesuatu yang sangat sederhana seperti membuat VM dengan dua NIC tidak dapat diselesaikan melalui GUI adalah kisah lain sepenuhnya. Direproduksi dengan izin dari Clusteringformeremortals.com

Pemulihan Bencana Untuk Edisi Standar SQL Server

Meniru Server Cluster 2-Node SQL Server Edisi 2012/2014 Ke Server Ketiga Untuk Pemulihan Bencana

Pemulihan bencana untuk Edisi Standar SQL Server dimungkinkan dengan SIOS DataKeeper Cluster Edition. Begini caranya. Banyak orang menemukan diri mereka menetap untuk SQL Server Standard Edition karena biaya SQL Server Enterprise Edition. SQL Server Standard Edition memiliki banyak fitur yang sama, tetapi hadir dengan beberapa keterbatasan. Salah satu batasannya adalah bahwa ia tidak mendukung Grup Ketersediaan AlwaysOn. Juga, ia hanya mendukung dua node dalam sebuah cluster. Dengan Pencerminan Database tidak lagi digunakan dan hanya mendukung replikasi sinkron dalam Edisi Standar, Anda benar-benar memiliki opsi pemulihan bencana yang terbatas.

Pemulihan bencana untuk Edisi Standar SQL Server

Salah satu opsi tersebut adalah SIOS DataKeeper Cluster Edition. DataKeeper akan bekerja dengan kluster penyimpanan bersama yang ada. Perangkat lunak ini memungkinkan Anda untuk memp^erluasnya ke node ketiga menggunakan replikasi sinkron atau asinkron. Jika Anda menggunakan SQL Server Enterprise, cukup tambahkan bahwa ^simpul ke-3 sebagai anggota kluster lain untuk kluster multisite yang benar. Namun, karena kita berbicara tentang SQL Server Edisi Standar, Anda tidak dapat menamba^hkan node ke-3 langsung ke kluster. Kabar baiknya adalah DataKeeper akan memungkinkan Anda untuk mereplikasi data ke ^node ketiga sehingga data Anda dilindungi. Pemulihan Bencana untuk SQL Server Standard Edition berarti Anda akan menggunakan DataKeeper untuk membawa nod^e ke-3 itu secara online sebagai sumber cermin. Selanjutnya gunakan SQL Server Management Studio untuk me-mount database yang ada pada volume direplikasi. Klien Anda juga perlu dialihkan ke node keti^ga ini. Tapi itu adalah solusi yang sangat efektif biaya dengan RPO yang sangat baik dan RTO yang wajar. Dokumentasi SIOS berbicara tentang bagaimana melakukan pemulihan Bencana untuk SQL Server Standard Edition. Di sini, saya telah meringkas langkah-langkah baru-baru ini untuk salah satu klien saya.

Konfigurasi

• Hentikan Sumber Daya SQL
• Hapus Sumber Daya Disk Fisik Dari Sumber Daya Cluster SQL
• Hapus Disk Fisik dari Penyimpanan Tersedia
• Disk Fisik Online pada server SECONDARY. Tambahkan huruf drive (jika tidak ada)
• Jalankan emcmd. setconfiguration <drive letter> 256 dan Reboot Secondary Server. Ini akan menyebabkan server SECONDARY memblokir akses ke driver E. Ini merupakan langkah penting karena Anda tidak ingin dua server memiliki akses ke drive E pada saat yang sama, jika Anda dapat menghindarinya.
• Online disk pada server PRIMARY
• Tambahkan huruf Drive jika diperlukan
• Buat Mirror DataKeeper dari Utama ke DR Anda mungkin harus menunggu satu menit agar drive E muncul di Laporan Ikhtisar ServerKeeper Server pada semua server sebelum Anda dapat membuat cermin dengan benar. Jika dilakukan dengan benar, Anda akan membuat cermin dari PRIMARY ke DR. Sebagai bagian dari proses itu DataKeeper akan menanyakan Anda tentang server SECONDARY yang berbagi volume yang Anda gandakan.

Dalam Event Of Disaster….

ON DR NODE

• Jalankan EMCMD. switchovervolume <huruf kandar>
• Pertama kali pastikan akun SQL Service memiliki akses baca / tulis ke semua data dan file log. Anda AKAN harus secara eksplisit memberikan akses ini saat pertama kali Anda mencoba untuk me-mount database.
• Gunakan SQL Management Studio untuk me-mount database
• Alihkan semua klien ke server di situs DR. Lebih baik lagi memiliki aplikasi yang berada di situs DR pra-dikonfigurasi untuk menunjuk ke contoh SQL Server di situs DR.

SETELAH BENCANA ADALAH LEBIH

• Power server (PRIMAY, SECONDARY) di situs utama kembali
• Tunggu sampai cermin mencapai status mirroring
• Tentukan node mana yang merupakan sumber sebelumnya (jalankan PowerShell sebagai administrator) get-clusterresource -Name “<DataKeeper Volume Resource name>” | get-clusterparameter
• Pastikan tidak ada DataKeeper Volume Resources yang online di klaster
• Mulai GUI DataKeeper pada satu node cluster. Selesaikan setiap kondisi otak terbagi (kemungkinan besar tidak ada) memastikan simpul DR dipilih sebagai sumber selama prosedur pemulihan otak ganda
• Di node yang dilaporkan sebagai sumber sebelumnya menjalankan EMCMD. switchovervolume <huruf kandar>
• Bawa SQL Server daring di Failover Cluster Manager

Langkah-langkah di atas mengasumsikan Anda memiliki SIOS DataKeeper Cluster Edition yang diinstal pada ketiga server (PRIMARY, SECONDARY, DR). PRIMARY dan SECONDARY adalah kelompok penyimpanan bersama dua node. Anda mereplikasi data ke DR yang hanya contoh SQL Server yang berdiri sendiri (bukan bagian dari gugus) hanya dengan penyimpanan terlampir lokal. Server Pemulihan Bencana akan memiliki volume (s) yang sama ukuran dan huruf drive sebagai volume cluster bersama (s). Ini berfungsi dengan baik dan bahkan akan memungkinkan Anda mereplikasi ke target yang ada di awan jika Anda tidak memiliki situs Pemulihan Disaster Anda sendiri yang dikonfigurasi. Anda juga dapat membangun konfigurasi yang sama menggunakan semua penyimpanan yang direplikasi jika Anda ingin menghilangkan SAN sepenuhnya. Berikut ini adalah video pendek yang bagus yang menggambarkan beberapa kemungkinan konfigurasi untuk pemulihan bencana untuk SQL Server Standard Edition. http://videos.us.sios.com/medias/aula05u2fl Direproduksi dengan izin dari Clusteringformeremortals.com

Layanan yang Didukung dengan Azure Resource Manager (ARM)

Manajemen Layanan Azure (Klasik) atau Azure Resource Manager (ARM)?

Saya berurusan dengan pengguna setiap minggu yang memindahkan beban kerja bisnis yang penting ke Azure. Pertanyaan pertama yang biasanya saya tanyakan adalah apakah mereka menggunakan Azure Service Management (Classic) atau Azure Resource Manager (ARM).

Saya biasanya merekomendasikan ARM. Ini adalah cara baru dalam melakukan sesuatu dan semua fitur baru sedang dikembangkan untuk ARM. Namun, ada beberapa hal yang tidak kompatibel dengan ARM. Seiring berjalannya waktu, daftar fitur yang tidak didukung ini semakin kecil dan semakin kecil. Sementara itu, baik untuk mengetahui ada dokumen yang ada yang tampaknya diperbarui secara berkala yang berisi daftar semua fitur dan apakah mereka didukung dengan ARM. https://azure.microsoft.com/en-us/documentation/articles/resource-manager-supported-services/

Ini daftar yang bagus tapi tidak lengkap. Saya hanya menemukan Lingkungan Layanan Aplikasi tidak didukung pada halaman ini di halaman App Service Environment.

Perbaiki Koneksi ILB Azure Di SQL Server Selalu di Failover Cluster Instance

Pemecahan Masalah Masalah Koneksi Azure ILB Dalam Koneksi Failover Instance Server SQL

Saya menggunakan alat berikut ini untuk membantu saya mengatasi masalah SQL Server Failover Cluster Instance Connectivity. Terutama masalah-masalah Azure ILB Connection yang mengganggu. Saya akan mencoba memperbarui artikel ini setiap kali saya menemukan alat baru.

NETSTAT

Alat pertama adalah tes sederhana untuk memverifikasi apakah SQL Cluster IP mendengarkan pada port yang seharusnya didengarkan. Dalam hal ini, alamat IP SQL Cluster adalah 10.0.0.201. Tetapi menggunakan instance default yaitu port 1433.

Di sini adalah perintah yang akan membantu Anda dengan cepat mengidentifikasi apakah simpul aktif mendengarkan pada port itu. Dalam kasus kami di bawah ini semuanya terlihat normal.

C:  Users  dave.SIOS> netstat -na | temukan "1433"
TCP 10.0.0.4:49584 10.0.0.201:1433 DIDIRIKAN
TCP 10.0.0.4:49592 10.0.0.201:1433 DIDIRIKAN
TCP 10.0.0.4:49593 10.0.0.201:1433 DIDIRIKAN
TCP 10.0.0.4:49595 10.0.0.201:1433 DIDIRIKAN
TCP 10.0.0.201:1433 0.0.0.0:0 MENDENGARKAN
MAPAN
TCP 10.0.0.201:1433 10.0.0.4:49592 DIDIRIKAN
TCP 10.0.0.201:1433 10.0.0.4:49593 DIDIRIKAN
TCP 10.0.0.201:1433 10.0.0.4:49595 DIDIRIKAN

Setelah saya dapat yakin SQL mendengarkan port yang tepat, saya menggunakan PSPING untuk mencoba menyambung ke port dari jarak jauh.

PSPING

PSPing adalah bagian dari paket PSTools yang tersedia dari Microsoft. Saya biasanya mengunduh alat dan menempatkan PSPing langsung di folder System32 saya sehingga saya dapat menggunakannya kapan pun saya mau tanpa harus mengubah direktori.

Sekarang, dengan asumsi semuanya sudah dikonfigurasi dengan benar dari perspektif ILB, Cluster dan Firewall, Anda harus dapat melakukan ping ke alamat IP dan port SQL Cluster 1433 dari server pasif. Anda akan mendapatkan hasil yang ditunjukkan di bawah ini …

C:  Users  dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01 - PsPing - ping, latency, utilitas pengukuran bandwidth
Hak Cipta (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP terhubung ke 10.0.0.201:1433:
5 iterasi (pemanasan 1) uji koneksi:
Menghubungkan ke 10.0.0.201:1433 (pemanasan): 6.99ms
Menghubungkan ke 10.0.0.201:1433: 0.78ms
Menghubungkan ke 10.0.0.201:1433: 0.96ms
Menghubungkan ke 10.0.0.201:1433: 0.68ms
Menghubungkan ke 10.0.0.201:1433: 0.89ms
Jika hal-hal tidak dikonfigurasi dengan benar, Anda dapat melihat hasil yang serupa dengan yang berikut ...
C:  Users  dave.SIOS> psping 10.0.0.201:1433
TCP terhubung ke 10.0.0.102:1433:
5 iterasi (pemanasan 1) uji koneksi:
Menghubungkan ke 10.0.0.102:1433 (pemanasan): 
Operasi ini kembali karena batas waktu habis.
Menghubungkan ke 10.0.0.102:1433 (pemanasan): 
Operasi ini kembali karena batas waktu habis.
Menghubungkan ke 10.0.0.102:1433 (pemanasan): 
Operasi ini kembali karena batas waktu habis.
Menghubungkan ke 10.0.0.102:1433 (pemanasan): 
Operasi ini kembali karena batas waktu habis.
Menghubungkan ke 10.0.0.102:1433 (pemanasan): 
Operasi ini kembali karena batas waktu habis.

Jika PSPing menghubungkan tetapi aplikasi Anda mengalami masalah koneksi, Anda mungkin perlu menggali lebih dalam. Saya telah melihat beberapa aplikasi seperti Great Plains juga ingin membuat koneksi ke port 445. Jika aplikasi Anda tidak dapat terhubung tetapi PSPing terhubung ke 1433. Kemudian Anda mungkin perlu melakukan pelacakan jaringan dan melihat port lain apa yang sedang coba terhubung ke aplikasi Anda. Langkah terakhir Anda adalah menambahkan aturan load balancing untuk port-port itu juga.

NAMA INSTANSI

Berencana untuk menggunakan contoh bernama? Anda harus memastikan Anda mengunci layanan TCP Anda untuk menggunakan port statis. Pada saat yang sama, Anda juga harus memastikan Anda menambahkan aturan ke load balancer untuk mengalihkan UDP 1434 untuk Layanan Browser SQL. Jika tidak, Anda tidak akan dapat terhubung ke instance bernama Anda.

FIREWALL

Membuka port TCP 1433 dan 59999 harus mencakup semua langkah manual yang diperlukan. Tetapi ketika memecahkan masalah koneksi, saya biasanya mematikan Windows Firewall untuk menghilangkan firewall sebagai kemungkinan penyebab masalah. Jangan lupa. Azure juga memiliki firewall yang disebut Network Security Groups. Jika ada yang mengubah itu dari default yang dapat memblokir lalu lintas juga.

RESOLUSI NAME

Coba ping nama gugus SQL. Ini harus menyelesaikan ke alamat IP gugus SQL Server. Meskipun saya telah melihat lebih dari beberapa kesempatan, data DNS A yang terkait dengan nama jaringan Cluster SQL menghilang secara misterius dari DNS. Jika itu terjadi, lanjutkan dan baca-iklan nama SQL Custer dan alamat IP sebagai catatan A dalam DNS.

SQL KONFIGURASI MANAJER

Di SQL Configuration Manager, Anda akan melihat SQL Cluster IP Address terdaftar dan port 1433. Jika kebetulan Anda menginstal sebuah Instance Bernama, Anda tentu perlu masuk ke sini dan mengunci port ke port tertentu dan membuat aturan load balancing merefleksikan port itu. Karena batasan ILB Azure hanya pada ILB per AG, saya benar-benar tidak melihat alasan yang sah untuk menggunakan instance bernama. Buat lebih mudah untuk diri sendiri dan gunakan saja contoh default dari SQL. (Pembaruan: mulai Oktober 2016, Anda BISA memiliki beberapa alamat IP per ILB, jadi Anda BISA memiliki beberapa contoh SQL yang dipasang di kluster.)

Direproduksi dengan izin dari Clustering For Mere Mortals.

Azure ILB Dalam ARM Untuk SQL Server Failover Cluster Instances

Mengonfigurasi ILB #AZURE Dalam ARM Untuk SQL Server Failover Cluster Instance Atau AG Menggunakan AZURE Powershell 1.0

Dalam posting sebelumnya saya pergi ke beberapa detail tentang cara mengkonfigurasi Azure ILB di ARM untuk SQL Server Failover Cluster atau sumber daya AG. Petunjuk dalam artikel itu ditulis sebelum GA dari Azure PowerShell 1.0. Dengan ketersediaan Azure PowerShell 1.0, skrip utama yang menciptakan ILB harus sedikit berbeda. Bagian artikel lainnya masih akurat. Namun, jika Anda menggunakan Azure PowerShell 1.0 atau yang lebih baru, skrip untuk membuat ILB yang dijelaskan dalam artikel itu harus seperti berikut.

#Mengganti nilai untuk variabel yang tercantum di bawah ini
$ ResourceGroupName = 'SIOS-EAST' # Nama Grup Sumber Daya di mana node SQL dikerahkan
$ FrontEndConfigurationName = 'FEEAST' #Anda dapat memberikan nama apa pun ke parameter ini.
$ BackendConfiguratioName = 'BEEAST' #Anda dapat memberikan nama apa pun ke parameter ini.
$ LoadBalancerName = 'ILBEAST' #Menyediakan Nama untuk objek keseimbangan Lokal Internal
$ Location = 'eastus2' # Masukkan lokasi pusat data dari SQL Deployements
$ subname = 'public' # Menyediakan nama Subnet di mana Nodes SQL ditempatkan
$ ILBIP = '10 .0.0.201 '# Berikan alamat IP untuk Listener atau Load Balancer
$ subnet = Dapatkan-AzureRMVirtualNetwork -ResourceGroupName $ ResourceGroupName | 
Get-AzureRMVirtualNetworkSubnetConfig –name $ subname
$ FEConfig = New-AzureRMLoadBalancerFrontendIpConfig -Name $ FrontEndConfigurationName 
-PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id
$ BackendConfig = New-AzureRMLoadBalancerBackendAddressPoolConfig 
-Nama $ BackendConfiguratioName
New-AzureRMLoadBalancer -Name $ LoadBalancerName -ResourceGroupName $ ResourceGroupName 
-Lokasi $ Lokasi -FrontendIpConfiguration $ FEConfig 
-BackendAddressKolam $ BackendConfig

Sisa artikel asli itu sama, tapi saya baru saja menyalinnya di sini untuk kemudahan penggunaan …

Menggunakan GUI

Sekarang ILB dibuat, kita harus melihatnya di Portal Azure di Grup Sumber Daya. Lihat gambar di bawah.

Sisa konfigurasi juga dapat diselesaikan melalui PowerShell, tetapi saya akan menggunakan GUI dalam contoh saya.

Jika Anda ingin menggunakan PowerShell, Anda mungkin bisa menyusun skrip dengan melihat artikel ini. Sayangnya, artikel ini membingungkan saya. Saya akan mencari tahu suatu hari nanti dan mencoba mendokumentasikannya dalam format yang mudah digunakan. Sampai sekarang, saya pikir GUI baik-baik saja untuk langkah selanjutnya.

Mari Kita Mulai

Ikuti bersama dengan tangkapan layar di bawah ini. Jika Anda tersesat, ikuti petunjuk navigasi di bagian atas Portal Azure untuk mencari tahu di mana kita berada.

Langkah pertama

• Klik tab pengaturan Backend Pool. Pilih kumpulan backend untuk memperbarui Set Ketersediaan dan Mesin Virtual. Simpan perubahan Anda.

• Konfigurasikan Load Balancer's Probe dengan mengklik Add pada tab Probe. Berikan nama probe dan konfigurasikan untuk menggunakan Port TCP 59999. Saya telah meninggalkan interval probe dan ambang batas yang tidak sehat diatur ke pengaturan default. Ini berarti akan membutuhkan 10 detik sebelum ILB menghilangkan simpul pasif dari daftar node aktif setelah failover. Klien Anda mungkin membutuhkan waktu hingga 10 detik untuk dialihkan ke nodus aktif baru. Pastikan untuk menyimpan perubahan Anda.

Langkah berikutnya

• Arahkan ke Tab Aturan Penyeimbang Beban dan tambahkan aturan baru. Berikan aturan nama yang masuk akal (SQL1433 atau sesuatu). Pilih port protokol TCP 1433 (dengan asumsi Anda menggunakan contoh default dari SQL Server). Pilih 1433 untuk port Backend juga. Untuk Backend Pool, kita akan memilih Backend Pool yang kita buat sebelumnya (BE). Untuk Probe itu kami juga akan memilih Probe yang kami buat sebelumnya.

Kami tidak ingin mengaktifkan persistensi Session tetapi kami ingin mengaktifkan Floating IP (Direct Server Return). Saya telah membiarkan batas waktu tidak aktif diatur ke pengaturan default. Anda mungkin ingin mempertimbangkan untuk meningkatkannya ke nilai maksimum. Alasannya adalah bahwa saya telah melihat beberapa aplikasi seperti pesan kesalahan log SAP setiap kali koneksi terputus dan perlu dibuat kembali.

• Pada titik ini ILB dikonfigurasi. Hanya ada satu langkah terakhir yang perlu dilakukan untuk SQL Server Failover Cluster. Kita perlu memperbarui SQL IP Cluster Resource hanya dengan cara yang sama seperti pada model penyebaran Classic. Untuk melakukan itu Anda perlu menjalankan skrip PowerShell berikut hanya pada salah satu dari node cluster. Buat catatan, SubnetMask = "255.255.255.255" bukan kesalahan. Gunakan mask 32 bit terlepas dari apa masker subnet Anda yang sebenarnya.

Satu Catatan Akhir

Dalam tes awal saya, saya masih tidak dapat terhubung ke nama Sumber Daya SQL bahkan setelah saya menyelesaikan semua langkah di atas. Setelah membenturkan kepalaku ke dinding selama beberapa jam, aku menemukan bahwa karena alasan tertentu, Sumber Daya Nama Cluster SQL tidak terdaftar dalam DNS. Saya tidak yakin bagaimana itu terjadi atau apakah itu akan terjadi secara konsisten, tetapi jika Anda mengalami kesulitan untuk menghubungkan, saya pasti akan memeriksa DNS dan menambahkan nama klaster SQL dan alamat IP sebagai catatan A baru jika belum ada di sana.

Dan tentu saja jangan lupakan Windows Firewall yang bagus. Anda harus membuat pengecualian untuk 1433 dan 59999 atau matikan saja sampai Anda mendapatkan semuanya dikonfigurasi dengan benar seperti yang saya lakukan. Anda mungkin ingin memanfaatkan Grup Keamanan Jaringan Azure, bukan Firewall Windows lokal untuk pengalaman yang lebih terpadu di seluruh sumber daya Azure Anda.

Semoga beruntung dan beri tahu saya bagaimana Anda membuat.

Kunjungi di sini untuk melihat bagaimana SIOS membantu perusahaan di seluruh dunia dengan membuat SQL Server Failover Cluster.

Direproduksi dengan izin dari Clustering For Mere Mortals.