Perencanaan dan penerapan Microsoft Azure Virtual Machines untuk SAP NetWeaver


Windows logo. Windows

Drive D:\ dalam Azure VM adalah drive nonpersisten, yang didukung oleh beberapa disk lokal pada simpul komputasi Azure. Karena tidak bergigi, ini berarti bahwa setiap perubahan yang dilakukan pada konten pada D:\ drive hilang ketika VM di-boot ulang. Dengan "perubahan apa pun", seperti file yang disimpan, direktori dibuat, aplikasi diinstal, dll.

Logo Linux. Linux

Azure VM Linux secara otomatis memasang drive di /mnt/resource yang merupakan drive nonpersisten yang didukung oleh disk lokal pada simpul komputasi Azure. Karena tidak bertahan, ini berarti bahwa setiap perubahan yang dilakukan pada konten di /mnt/resource akan hilang ketika VM di-boot ulang. Dengan perubahan apa pun, seperti file yang disimpan, direktori yang dibuat, aplikasi yang dipasang, dll.

Akun Azure Storage

Saat menyebarkan layanan atau VM di Azure, penyebaran VHD dan Gambar VM diatur dalam unit yang disebut Akun Azure Storage. Akun penyimpanan Azure memiliki batasan baik dalam IOPS, throughput, atau ukuran yang dapat dimuat. Di masa lalu batasan ini, yang didokumentasikan dalam:

memainkan peran penting dalam merencanakan penyebaran SAP di Azure. Itu pada Anda untuk mengelola jumlah disk yang bertahan dalam akun penyimpanan. Anda perlu mengelola akun penyimpanan dan akhirnya membuat akun penyimpanan baru untuk membuat disk yang lebih bertahan.

Dalam beberapa tahun terakhir, pengenalan disk yang dikelola Azure membebaskan Anda dari tugas-tugas itu. Rekomendasi untuk penyebaran SAP adalah memanfaatkan disk yang dikelola Azure alih-alih mengelola akun penyimpanan Azure sendiri. Disk yang dikelola Azure akan mendistribusikan disk di berbagai akun penyimpanan, sehingga batas akun penyimpanan individual tidak terlampaui.

Dalam akun penyimpanan, Anda memiliki jenis konsep folder yang disebut 'kontainer' yang dapat digunakan untuk mengelompokkan disk tertentu ke dalam kontainer tertentu.

Dalam Azure, nama disk/VHD mengikuti koneksi penamaan berikut yang perlu memberikan nama unik untuk VHD di Azure:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

String di atas perlu mengidentifikasi disk/VHD yang disimpan secara unik di Azure Storage.

Jenis penyimpanan Azure persisten

Azure menawarkan berbagai opsi penyimpanan persisten yang dapat digunakan untuk beban kerja SAP dan komponen tumpukan SAP tertentu. Untuk detail lebih lanjut, baca dokumen Penyimpanan Azure untuk beban kerja SAP.

Jaringan Microsoft Azure

Microsoft Azure menyediakan infrastruktur jaringan, yang memungkinkan pemetaan semua skenario, yang ingin kami wujudkan dengan perangkat lunak SAP. Kemampuannya adalah:

  • Akses dari luar, langsung ke VM melalui Layanan Windows Terminal atau ssh/VNC
  • Akses ke layanan dan port tertentu yang digunakan oleh aplikasi dalam VM
  • Komunikasi Internal dan Resolusi Nama antara sekelompok VM yang digunakan sebagai Azure VMs
  • Konektivitas lintas lokasi antara jaringan lokal pelanggan dan jaringan Azure
  • Cross Azure Region atau konektivitas pusat data antara situs Azure

Informasi selengkapnya dapat ditemukan di sini: https://azure.microsoft.com/documentation/services/virtual-network/

Ada banyak kemungkinan berbeda untuk mengonfigurasi nama dan resolusi IP di Azure. Ada juga layanan Azure DNS, yang dapat digunakan sebagai pengganti menyiapkan server DNS Anda sendiri. Informasi lebih lanjut dapat ditemukan di artikel ini dan di halaman ini.

Untuk skenario lintas lokasi atau hibrid, kami mengandalkan fakta bahwa AD/OpenLDAP/DNS lokal telah diperluas melalui VPN atau koneksi pribadi ke Azure. Untuk skenario tertentu seperti yang didokumentasikan di sini, mungkin perlu memasang replika AD/OpenLDAP di Azure.

Karena jaringan dan resolusi nama adalah bagian penting dari penyebaran database untuk sistem SAP, konsep ini dibahas secara lebih rinci dalam Panduan Penyebaran DBMS.

Azure Virtual Network

Dengan membangun Virtual Network Azure, Anda dapat menentukan rentang alamat IP pribadi yang dialokasikan oleh fungsionalitas Azure DHCP. Dalam skenario lintas lokasi, rentang alamat IP yang ditentukan masih dialokasikan menggunakan DHCP oleh Azure. Namun, resolusi Nama Domain dilakukan di tempat (dengan asumsi bahwa VM adalah bagian dari domain lokal) dan karenanya dapat mengatasi alamat di luar Azure Cloud Services yang berbeda.

Setiap Mesin Virtual di Azure harus terhubung ke Virtual Network.

Informasi lebih lanjut dapat ditemukan di artikel ini dan di halaman ini.

Catatan

Secara default, setelah VM diterapkan, Anda tidak dapat mengubah konfigurasi Virtual Network. Pengaturan TCP/IP harus ditinggalkan ke server Azure DHCP. Perilaku default adalah penetapan IP Dinamis.

Alamat MAC kartu jaringan virtual dapat berubah, misalnya setelah mengubah ukuran dan OS tamu Windows atau Linux mengambil kartu jaringan baru dan secara otomatis menggunakan DHCP untuk menetapkan alamat IP dan DNS dalam kasus ini.

Penetapan IP Statis

Dimungkinkan untuk menetapkan alamat IP tetap atau dicadangkan ke VM dalam Virtual Network Azure. Menjalankan VM di Azure Virtual Network membuka kemungkinan besar untuk memanfaatkan fungsionalitas ini jika diperlukan atau diperlukan untuk beberapa skenario. Penetapan IP tetap berlaku selama keberadaan VM, terlepas dari apakah VM berjalan atau mati. Akibatnya, Anda perlu memperhitungkan jumlah VM secara keseluruhan (menjalankan dan menghentikan VM) saat menentukan rentang alamat IP untuk Virtual Network. Alamat IP tetap ditetapkan baik sampai VM dan Antarmuka Jaringannya dihapus atau sampai alamat IP tidak ditetapkan lagi. Untuk mengetahui informasi selengkapnya, baca artikel ini.

Catatan

Anda harus menetapkan alamat IP statis melalui Azure berarti untuk vNIC individual. Anda tidak boleh menetapkan alamat IP statik dalam OS tamu ke vNIC. Beberapa layanan Azure seperti Layanan Azure Backup bergantung pada fakta bahwa setidaknya vNIC utama diatur ke DHCP dan bukan ke alamat IP statik. Lihat juga dokumen Memecahkan masalah pencadangan mesin virtual Azure.

Alamat IP sekunder untuk virtualisasi nama host SAP

Setiap kartu antarmuka jaringan Komputer Virtual Azure dapat memiliki beberapa alamat IP yang ditetapkan untuk itu, IP sekunder ini dapat digunakan untuk nama host virtual SAP yang dipetakan ke catatan DNS A/PTR jika diperlukan. Alamat IP sekunder harus ditetapkan ke konfigurasi IP Azure vNICs sesuai artikel ini dan juga dikonfigurasi dalam OS karena IP sekunder tidak ditetapkan melalui DHCP. Setiap IP sekunder harus dari subnet yang sama dengan vNIC. Penggunaan IP mengambang Azure Load Balancer tidak didukung secara sekunder untuk konfigurasi IP sekunder seperti kluster Pacemaker, dalam hal ini IP Load Balancer mengaktifkan nama host virtual SAP. Lihat juga catatan SAP #962955 tentang panduan umum menggunakan nama host virtual.

Beberapa NIC per VM

Anda dapat menentukan beberapa kartu antarmuka jaringan virtual (vNIC) untuk Azure Virtual Machine. Dengan kemampuan untuk memiliki beberapa vNIC Anda dapat mulai mengatur pemisahan lalu lintas jaringan yang, misalnya, lalu lintas klien dialihkan melalui satu vNIC dan lalu lintas backend dialihkan melalui vNIC kedua. Tergantung pada jenis VM ada batasan yang berbeda untuk jumlah vNIC yang dapat ditetapkan VM. Detail, fungsionalitas, dan pembatasan yang tepat dapat ditemukan di artikel ini:

Konektivitas Situs-ke-Situs

Lintas lokasi adalah Azure VMs dan On-Premises yang ditautkan dengan koneksi VPN transparan dan permanen. Ini diharapkan menjadi pola penyebaran SAP yang paling umum di Azure. Asumsinya adalah bahwa prosedur dan proses operasional dengan instans SAP di Azure harus bekerja secara transparan. Ini berarti Anda harus dapat mencetak keluar dari sistem ini serta menggunakan SAP Transport Management System (TMS) untuk mengangkut perubahan dari sistem pengembangan di Azure ke sistem uji, yang digunakan di tempat. Dokumentasi lainnya seputar situs ke situs dapat ditemukan di artikel ini

Perangkat Terowongan VPN

Untuk membuat koneksi situs ke situs (pusat data lokal ke pusat data Azure), Anda perlu mendapatkan dan mengonfigurasi perangkat VPN, atau menggunakan Routing and Remote Access Service (RRAS) yang diperkenalkan sebagai komponen perangkat lunak dengan Windows Server 2012.

Koneksi situs-ke-situs antara lokal dan Azure

Gambar di atas menunjukkan dua langganan Azure memiliki subrentang alamat IP yang dicadangkan untuk penggunaan di Virtual Network di Azure. Konektivitas dari jaringan lokal ke Azure ditetapkan melalui VPN.

VPN Poin-ke-Situs

VPN poin-ke-situs mengharuskan setiap mesin klien untuk terhubung dengan VPN-nya sendiri ke Azure. Untuk skenario SAP, kami melihat, konektivitas poin-ke-situs tidak praktis. Oleh karena itu, tidak ada referensi lebih lanjut yang diberikan kepada konektivitas VPN poin-ke-situs.

Informasi selengkapnya dapat ditemukan di sini

VPN Multi-Situs

Azure juga saat ini menawarkan kemungkinan untuk membuat konektivitas VPN Multi-Situs untuk satu langganan Azure. Sebelumnya satu langganan dibatasi untuk satu koneksi VPN situs-ke-situs. Batasan ini hilang dengan koneksi VPN Multi-Situs untuk satu langganan. Hal ini memungkinkan untuk memanfaatkan lebih dari satu Wilayah Azure untuk langganan tertentu melalui konfigurasi lintas lokasi.

Untuk dokumentasi lainnya, lihat artikel ini

Koneksi VNet ke VNet

Menggunakan VPN Multi-Situs, Anda perlu mengonfigurasi Virtual Network Azure terpisah di setiap wilayah. Namun seringkali Anda memiliki persyaratan bahwa komponen perangkat lunak di berbagai wilayah harus berkomunikasi satu sama lain. Idealnya komunikasi ini tidak boleh dirutekan dari satu Wilayah Azure ke lokal dan dari sana ke Wilayah Azure lainnya. Untuk pintasan, Azure menawarkan kemungkinan untuk mengonfigurasi koneksi dari satu Virtual Network Azure di satu wilayah ke Virtual Network Azure lain yang dihosting di wilayah lain. Fungsionalitas ini disebut koneksi VNet-ke-VNet. Detail lebih lanjut tentang fungsi ini dapat ditemukan di sini: https://azure.microsoft.com/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/.

Koneksi Pribadi ke Azure ExpressRoute

Microsoft Azure ExpressRoute memungkinkan pembuatan koneksi pribadi antara pusat data Azure dan infrastruktur lokal pelanggan atau di lingkungan lokasi bersama. ExpressRoute ditawarkan oleh berbagai penyedia VPN MPLS (paket switched) atau Penyedia Layanan Jaringan lainnya. Sambungan ExpressRoute tidak melalui Internet publik. Koneksi ExpressRoute menawarkan keamanan yang lebih tinggi, lebih banyak keandalan melalui beberapa sirkuit paralel, kecepatan yang lebih cepat, dan keterlambatan yang lebih rendah daripada koneksi umum melalui Internet.

Temukan detail selengkapnya tentang Azure ExpressRoute dan penawaran di sini:

Express Route memungkinkan beberapa langganan Azure melalui satu sirkuit ExpressRoute seperti yang didokumentasikan di sini

Terowongan paksa jika terjadi lintas lokasi

Untuk VM yang bergabung dengan domain lokal melalui situs ke situs, poin-ke-situs, atau ExpressRoute, Anda perlu memastikan bahwa pengaturan proksi Internet juga diterapkan untuk semua pengguna di VM tersebut. Secara default, perangkat lunak yang berjalan di VM atau pengguna yang menggunakan browser untuk mengakses internet tidak akan melalui proksi perusahaan, tetapi akan terhubung langsung melalui Azure ke internet. Tetapi bahkan pengaturan proksi bukan solusi 100% untuk mengarahkan lalu lintas melalui proksi perusahaan karena bertanggung jawab atas perangkat lunak dan layanan untuk memeriksa proksi. Jika perangkat lunak yang berjalan di VM tidak melakukan itu atau admin memanipulasi pengaturan, lalu lintas ke Internet dapat memutar lagi langsung melalui Azure ke Internet.

Untuk menghindari konektivitas internet langsung seperti itu, Anda dapat mengonfigurasi Forced Tunneling dengan konektivitas situs ke situs antara lokal dan Azure. Deskripsi terperinci dari fitur Forced Tunneling diterbitkan di sini https://azure.microsoft.com/documentation/articles/vpn-gateway-forced-tunneling-rm/

Forced Tunneling dengan ExpressRoute diaktifkan oleh pelanggan yang mengiklankan rute default melalui sesi peering BGP ExpressRoute.

Ringkasan jaringan Azure

Bab ini berisi banyak poin penting tentang Azure Networking. Berikut adalah ringkasan poin utama:

  • Azure Virtual Networks memungkinkan Anda memasukkan struktur jaringan ke dalam penyebaran Azure Anda. VNet dapat diisolasi satu sama lain atau dengan bantuan traffic Kelompok Keamanan Jaringan antara VNet dapat dikontrol.
  • Azure Virtual Networks dapat dimanfaatkan untuk menetapkan rentang alamat IP ke VM atau menetapkan alamat IP tetap ke VM
  • Untuk menyiapkan koneksi Situs-ke-Situs atau Poin-ke-Situs, Anda perlu membuat Virtual Network Azure terlebih dahulu
  • Setelah mesin virtual disebarkan, tidak mungkin lagi mengubah Virtual Network yang ditetapkan ke VM

Kuota dalam Layanan mesin virtual Azure

Kita harus jelas tentang fakta bahwa penyimpanan dan infrastruktur jaringan dibagi antara VM yang menjalankan berbagai layanan di infrastruktur Azure. Seperti di pusat data pelanggan sendiri, penyediaan sumber daya infrastruktur secara berlebihan memang berlangsung hingga satu derajat. Microsoft Azure Platform menggunakan disk, CPU, jaringan, dan kuota lainnya untuk membatasi konsumsi sumber daya dan untuk mempertahankan kinerja yang konsisten dan deterministik. Tipe VM yang berbeda (A5, A6, dll.) memiliki kuota yang berbeda untuk jumlah disk, CPU, RAM, dan Jaringan.

Catatan

Sumber daya CPU dan memori dari jenis VM yang didukung oleh SAP telah dialokasikan sejak awal pada node host. Ini berarti bahwa setelah VM digunakan, sumber daya pada host tersedia seperti yang ditentukan oleh jenis VM.

Saat merencanakan dan mengubah ukuran SAP pada solusi Azure, kuota untuk setiap ukuran mesin virtual harus dipertimbangkan. Kuota VM dijelaskan di sini (Linux) dan di sini (Windows).

Kuota yang dijelaskan mewakili nilai maksimum teoritis. Batas IOPS per disk dapat dicapai dengan I/Os kecil (8 KB) tetapi mungkin tidak tercapai dengan I/Os besar (1 MB). Batas IOPS diberlakukan pada granularitas disk tunggal.

Sebagai pohon keputusan kasar untuk memutuskan apakah sistem SAP cocok dengan Azure Virtual Machine Services dan kemampuannya atau apakah sistem yang ada perlu dikonfigurasikan secara berbeda untuk menyebarkan sistem di Azure, pohon keputusan di bawah ini dapat digunakan:

Pohon keputusan untuk memutuskan kemampuan untuk menyebarkan SAP di Azure

  1. Informasi yang paling penting untuk memulai adalah persyaratan SAPS untuk sistem SAP tertentu. Persyaratan SAPS perlu dipisahkan ke bagian DBMS dan bagian aplikasi SAP, bahkan jika sistem SAP sudah disebarkan di tempat dalam konfigurasi 2 tingkat. Untuk sistem yang ada, SAPS yang terkait dengan perangkat keras yang digunakan sering dapat ditentukan atau diperkirakan berdasarkan tolok ukur SAP yang ada. Hasilnya dapat ditemukan di halaman Tentang Tolok Ukur Aplikasi Standar SAP. Untuk sistem SAP yang baru diterapkan, Anda harus melalui latihan ukuran, yang harus menentukan persyaratan SAPS dari sistem.
  2. Untuk sistem yang ada, volume I/O dan operasi I/O per detik di server DBMS harus diukur. Untuk sistem yang baru direncanakan, latihan sizing untuk sistem baru juga harus memberikan gagasan kasar tentang persyaratan I/O di sisi DBMS. Jika tidak yakin, Anda akhirnya perlu melakukan Bukti Konsep.
  3. Bandingkan persyaratan SAPS untuk server DBMS dengan SAPS yang dapat menyediakan jenis VM Azure yang berbeda. Informasi tentang SAPS dari berbagai jenis Azure VM didokumentasikan dalam SAP Note 1928533. Fokusnya harus pada DBMS VM terlebih dahulu karena lapisan database adalah lapisan dalam sistem SAP NetWeaver yang tidak menskalakan dalam sebagian besar penyebaran. Sebaliknya, lapisan aplikasi SAP dapat diskalakan. Jika tidak ada jenis Azure VM yang didukung SAP yang dapat memberikan SAPS yang diperlukan, beban kerja sistem SAP yang direncanakan tidak dapat dijalankan di Azure. Anda perlu menyebarkan sistem lokal atau Anda perlu mengubah volume beban kerja untuk sistem.
  4. Seperti yang didokumentasikan di sini (Linux) dan di sini (Windows), Azure memberlakukan kuota IOPS per disk independen apakah Anda menggunakan Standard Storage atau Premium Storage. Tergantung pada jenis VM, jumlah disk data, yang dapat dipasang bervariasi. Akibatnya, Anda dapat menghitung angka IOPS maksimum yang dapat dicapai dengan masing-masing jenis VM yang berbeda. Tergantung pada tata letak file database, Anda dapat menghapus disk untuk menjadi satu volume di OS tamu. Namun, jika volume IOPS saat ini dari sistem SAP yang diterapkan melebihi batas terhitung dari jenis VM terbesar Azure dan jika tidak ada kesempatan untuk mengompensasi dengan lebih banyak memori, beban kerja sistem SAP dapat sangat terdampak. Dalam kasus seperti itu, Anda dapat mencapai titik di mana Anda tidak boleh menyebarkan sistem di Azure.
  5. Terutama dalam sistem SAP, yang diterapkan di tempat dalam konfigurasi 2 Tingkat, kemungkinan sistem mungkin perlu dikonfigurasi di Azure dalam konfigurasi 3 Tingkat. Dalam langkah ini, Anda perlu memeriksa apakah ada komponen dalam lapisan aplikasi SAP, yang tidak dapat diskalakan dan yang tidak akan masuk ke dalam CPU dan sumber daya memori yang ditawarkan jenis Azure VM yang berbeda. Jika memang ada komponen seperti itu, sistem SAP dan beban kerjanya tidak dapat disebarkan ke Azure. Tetapi jika Anda dapat menskalakan komponen aplikasi SAP ke beberapa Azure VM, sistem dapat digunakan ke Azure.

Jika komponen lapisan aplikasi DBMS dan SAP dapat dijalankan di Azure VMs, konfigurasi perlu didefinisikan sehubungan dengan:

  • Jumlah VM Azure
  • Jenis VM untuk komponen individual
  • Jumlah VHD dalam DBMS VM untuk menyediakan IOPS yang cukup

Mengelola aset Azure

portal Microsoft Azure

portal Azure adalah salah satu dari tiga antarmuka untuk mengelola penyebaran Azure VM. Tugas manajemen dasar, seperti menyebarkan VM dari gambar, dapat dilakukan melalui portal Azure. Selain itu, pembuatan Akun Azure Storage, Jaringan Virtual, dan komponen Azure lainnya juga merupakan tugas yang dapat ditangani portal Azure dengan baik. Namun, fungsionalitas seperti mengunggah VHD dari lokal ke Azure atau menyalin VHD dalam Azure adalah tugas, yang memerlukan alat atau administrasi pihak ketiga melalui PowerShell atau CLI.

portal Microsoft Azure - Gambaran umum Komputer Virtual

Tugas administrasi dan konfigurasi untuk instans Komputer Virtual dimungkinkan dari dalam portal Azure.

Selain memulai ulang dan mematikan Komputer Virtual, Anda juga dapat memasang, melepas, dan membuat disk data untuk instans Komputer Virtual, untuk menangkap instans untuk persiapan gambar, dan mengonfigurasikan ukuran instans Komputer Virtual.

portal Azure menyediakan fungsionalitas dasar untuk menyebarkan dan mengonfigurasikan VM dan banyak layanan Azure lainnya. Namun tidak semua fungsionalitas yang tersedia dicakup oleh portal Azure. Di portal Azure, tidak dimungkinkan untuk melakukan tugas seperti:

  • Mengunggah VHD ke Azure
  • Menyalin VM

Manajemen melalui cmdlet Microsoft Azure PowerShell

Windows PowerShell adalah kerangka kerja yang canggih dan dapat diperluas yang telah diadopsi secara luas oleh pelanggan yang menyebarkan sejumlah besar sistem di Azure. Setelah instalasi cmdlet PowerShell di desktop, laptop atau stasiun manajemen khusus, cmdlet PowerShell dapat dijalankan dari jarak jauh.

Proses untuk mengaktifkan desktop / laptop lokal untuk penggunaan cmdlet Azure PowerShell dan cara mengonfigurasikannya untuk penggunaan dengan langganan Azure dijelaskan dalam artikel ini.

Langkah-langkah lebih terperinci tentang cara menginstal, memperbarui, dan mengonfigurasi cmdlet Azure PowerShell juga dapat ditemukan di Menginstal modul Azure PowerShell. Pengalaman pelanggan sejauh ini memperlihatkan bahwa PowerShell tentu saja merupakan alat yang lebih kuat untuk menyebarkan VM dan membuat langkah-langkah khusus dalam penyebaran VM. Semua pelanggan yang menjalankan instans SAP di Azure menggunakan cmdlet PowerShell untuk melengkapi tugas manajemen yang mereka lakukan di portal Microsoft Azure atau bahkan menggunakan cmdlet PowerShell secara eksklusif untuk mengelola penyebaran mereka di Azure. Karena cmdlet khusus Azure memiliki konvensi penamaan yang sama dengan lebih dari 2000 cmdlet terkait Windows, ini adalah tugas yang mudah bagi admin Windows untuk memanfaatkan cmdlet tersebut.

Lihat contoh di sini: https://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx

Penyebaran Azure Extension untuk SAP (lihat bab Azure Extension untuk SAP dalam dokumen ini) hanya dimungkinkan melalui PowerShell atau CLI. Oleh karena itu wajib untuk mengatur dan mengonfigurasikan PowerShell atau CLI saat menyebarkan atau mengelola sistem SAP NetWeaver di Azure.

Karena Azure menyediakan lebih banyak fungsi, cmdlet PowerShell baru akan ditambahkan sehingga pembaruan cmdlet diperlukan. Oleh karena itu masuk akal untuk memeriksa situs Unduhan Azure setidaknya sekali bulan https://azure.microsoft.com/downloads/ untuk versi baru cmdlet. Versi baru dipasang di atas versi yang lebih lama.

Untuk daftar umum perintah PowerShell terkait Azure, periksa di sini: Dokumentasi Azure PowerShell.

Manajemen melalui perintah Microsoft Azure CLI

Untuk pelanggan yang menggunakan Linux dan ingin mengelola sumber daya Azure PowerShell mungkin bukan pilihan. Microsoft menawarkan Azure CLI sebagai alternatif. Azure CLI menyediakan serangkaian perintah sumber terbuka, lintas platform untuk bekerja dengan Azure Platform. Azure CLI menyediakan banyak fungsionalitas yang sama yang ditemukan di portal Azure.

Untuk informasi tentang penginstalan, konfigurasi, dan cara menggunakan perintah CLI untuk menyelesaikan tugas Azure lihat

Langkah pertama merencanakan penyebaran

Langkah pertama dalam perencanaan penyebaran adalah TIDAK memeriksa VM yang tersedia untuk menjalankan SAP. Langkah pertama dapat menjadi salah satu langkah yang memakan waktu, tetapi yang paling penting, adalah bekerja dengan tim kepatuhan dan keamanan di perusahaan Anda tentang apa saja batas kondisi untuk menyebarkan jenis beban kerja SAP atau proses bisnis ke cloud publik. Jika perusahaan Anda menyebarkan perangkat lunak lain sebelumnya ke Azure, prosesnya bisa mudah. Jika perusahaan Anda lebih pada awal perjalanan, mungkin ada diskusi yang lebih besar yang diperlukan untuk mengetahui kondisi batas, kondisi keamanan, yang memungkinkan data SAP tertentu dan proses bisnis SAP untuk dihosting di cloud publik.

Sebagai bantuan yang berguna, Anda dapat merujuk ke Penawaran kepatuhan Microsoft untuk daftar penawaran kepatuhan yang dapat ditawarkan Microsoft.

Area lain yang perlu diperhatikan seperti enkripsi data untuk data saat tidak aktif atau enkripsi lain di layanan Azure didokumentasikan dalam Gambaran umum enkripsi Azure.

Jangan meremehkan fase proyek ini dalam perencanaan Anda. Hanya ketika Anda memiliki perjanjian dan aturan seputar topik ini, Anda harus pergi ke langkah berikutnya, yaitu perencanaan arsitektur jaringan yang Anda sebarkan di Azure.

Berbagai cara untuk menyebarkan VM untuk SAP di Azure

Dalam bab ini, Anda mempelajari berbagai cara untuk menyebarkan VM di Azure. Prosedur persiapan tambahan, serta penanganan VHD dan VM di Azure tercakup dalam bab ini.

Penyebaran VM untuk SAP

Microsoft Azure menawarkan beberapa cara untuk menyebarkan VM dan disk terkait. Dengan demikian penting untuk memahami perbedaan karena persiapan VM mungkin berbeda tergantung pada metode penyebaran. Secara umum, kami melihat skenario berikut:

Memindahkan VM dari lokal ke Azure dengan disk yang tidak digeneralisasi

Anda berencana memindahkan sistem SAP tertentu dari lokal ke Azure. Ini dapat dilakukan dengan mengunggah VHD, yang berisi OS, Biner SAP, dan biner DBMS ditambah VHD dengan data dan file log DBMS ke Azure. Berbeda dengan skenario #2 bawah ini, Anda menyimpan akun pengguna nama host, SAP SID, dan SAP di Azure VM saat dikonfigurasikan di lingkungan lokal. Oleh karena itu, generalisasi gambar tidak diperlukan. Lihat bab Persiapan untuk memindahkan VM dari lokal ke Azure dengan disk non-generalisasi dari dokumen ini untuk langkah-langkah persiapan lokal dan pengunggahan VM atau VHD non-generalisasi ke Azure. Baca bab Skenario 3: Memindahkan VM dari lokal menggunakan Azure VHD non-generalisasi dengan SAP di Panduan Penyebaran untuk langkah-langkah terperinci dalam menyebarkan gambar tersebut di Azure.

Opsi lain yang tidak akan kami bahas secara rinci dalam panduan ini adalah menggunakan Azure Site Recovery untuk mereplikasi Server Aplikasi SAP NetWeaver dan Layanan Pusat SAP NetWeaver ke Azure. Kami tidak menyarankan untuk menggunakan Azure Site Recovery untuk lapisan database dan lebih menggunakan mekanisme replikasi spesifik database, seperti HANA System Replication. Untuk informasi selengkapnya, lihat bab Lindungi SAP dari Tentang pemulihan bencana untuk panduan aplikasi lokal.

Menyebarkan VM dengan gambar khusus pelanggan

Karena persyaratan patch tertentu dari OS atau versi DBMS Anda, gambar yang disediakan di Azure Marketplace mungkin tidak sesuai dengan kebutuhan Anda. Oleh karena itu, Anda mungkin perlu membuat VM menggunakan gambar OS/DBMS VM privat Anda sendiri, yang dapat digunakan beberapa kali setelahnya. Untuk menyiapkan gambar privat seperti itu untuk duplikasi, item berikut harus dipertimbangkan:


Windows logo. Windows

Untuk detail selengkapnya, baca Mengunggah VHD Windows yang digeneralisasi dan menggunakannya untuk membuat VM baru di Azure Pengaturan Windows (seperti Windows SID dan nama host) harus diabstraksikan/digeneralisasi pada VM lokal melalui perintah sysprep.

Logo Linux. Linux

Ikuti langkah-langkah yang dijelaskan dalam artikel ini untuk SUSE, Red Hat, atau Oracle Linux, untuk menyiapkan VHD yang akan diunggah ke Azure.


Jika Anda telah memasang konten SAP di VM lokal Anda (terutama untuk sistem 2-Tingkat), Anda dapat menyesuaikan pengaturan sistem SAP setelah penyebaran Azure VM melalui prosedur ganti nama instans yang didukung oleh SAP Software Provisioning Manager (SAP Note 1619720). Lihat bab Persiapan untuk menyebarkan VM dengan gambar khusus pelanggan untuk SAP dan Mengunggah VHD dari lokal ke Azure dokumen ini untuk langkah-langkah persiapan lokal dan unggah VM yang digeneralisasi ke Azure. Baca bab Skenario 2: Menyebarkan VM dengan gambar kustom untuk SAP di Panduan Penyebaran untuk langkah-langkah terperinci menyebarkan gambar tersebut di Azure.

Menyebarkan VM dari Azure Marketplace

Anda ingin menggunakan gambar VM yang disediakan Microsoft atau pihak ketiga dari Azure Marketplace untuk menyebarkan VM Anda. Setelah menyebarkan VM di Azure, ikuti panduan dan alat yang sama untuk menginstal perangkat lunak SAP dan/atau DBMS di dalam VM seperti yang akan Anda lakukan di lingkungan lokal. Untuk deskripsi penyebaran yang lebih rinci, lihat bab Skenario 1: Menyebarkan VM dari Azure Marketplace untuk SAP di Panduan Penyebaran.

Menyiapkan VM dengan SAP untuk Azure

Sebelum mengunggah VM ke Azure, Anda perlu memastikan VM dan VHD memenuhi persyaratan tertentu. Ada perbedaan kecil tergantung pada metode penyebaran yang digunakan.

Persiapan untuk memindahkan VM dari lokal ke Azure dengan disk yang tidak digeneralisasi

Metode penyebaran umum adalah memindahkan VM yang ada, yang menjalankan sistem SAP dari lokal ke Azure. VM dan sistem SAP di VM hanya harus berjalan di Azure menggunakan nama host yang sama dan kemungkinan SAP SID yang sama. Dalam hal ini, OS tamu VM tidak boleh digeneralisasi untuk beberapa penyebaran. Jika jaringan lokal diperluas ke Azure, maka bahkan akun domain yang sama dapat digunakan dalam VM seperti yang digunakan sebelum yang lokal.

Persyaratan saat menyiapkan Disk Azure VM Anda sendiri adalah:

  • Awalnya VHD yang berisi sistem operasi bisa memiliki ukuran maksimum 127 GB saja. Keterbatasan ini dihilangkan pada akhir Maret 2015. Sekarang VHD yang berisi sistem operasi dapat berukuran hingga 1 TB seperti yang juga dihosting VHD oleh Azure Storage lainnya.
  • Ini harus dalam format VHD tetap. VHD atau VHD dinamis dalam format VHDx belum didukung di Azure. VHD dinamis akan dikonversi ke VHD statis saat Anda mengunggah VHD dengan commandlet PowerShell atau CLI
  • VHD, yang dipasang ke VM dan harus dipasang lagi di Azure ke VM juga harus dalam format VHD tetap. Baca artikel ini untuk batas ukuran disk data. VHD dinamis akan dikonversi ke VHD statis saat Anda mengunggah VHD dengan commandlet PowerShell atau CLI
  • Tambahkan akun lokal lain dengan hak istimewa admin, yang dapat digunakan oleh dukungan Microsoft atau yang dapat ditetapkan sebagai konteks untuk layanan dan aplikasi untuk dijalankan sampai VM disebarkan dan pengguna yang lebih tepat dapat digunakan.
  • Tambahkan akun lokal lain karena mungkin diperlukan untuk skenario penyebaran tertentu.

Windows logo. Windows

Dalam skenario ini tidak ada generalisasi (sysprep) VM yang diperlukan untuk mengunggah dan menggunakan VM di Azure. Pastikan drive D:\ tidak digunakan. Atur automount disk untuk disk terlampir seperti yang dijelaskan dalam bab Mengatur automount untuk disk yang dilampirkan dalam dokumen ini.

Logo Linux. Linux

Dalam skenario ini tidak ada generalisasi (waagent -deprovision) VM yang diperlukan untuk mengunggah dan menggunakan VM di Azure. Pastikan /mnt/resource tidak digunakan dan SEMUA disk dipasang melalui uuid. Untuk disk OS, pastikan bahwa entri bootloader juga mencerminkan dudukan berbasis uuid.


Persiapan untuk menyebarkan VM dengan gambar khusus pelanggan untuk SAP

File VHD yang berisi OS umum disimpan dalam kontainer di Akun Azure Storage atau sebagai gambar Disk Terkelola. Anda dapat menerapkan VM baru dari gambar tersebut dengan merujuk gambar VHD atau Disk Terkelola sebagai sumber dalam file templat penyebaran Anda seperti yang dijelaskan dalam bab Skenario 2: Menyebarkan VM dengan gambar kustom untuk SAP dari Panduan Penyebaran.

Persyaratan saat menyiapkan Gambar Azure VM Anda sendiri adalah:

  • Awalnya VHD yang berisi sistem operasi bisa memiliki ukuran maksimum 127 GB saja. Keterbatasan ini dihilangkan pada akhir Maret 2015. Sekarang VHD yang berisi sistem operasi dapat berukuran hingga 1 TB seperti yang juga dihosting VHD oleh Azure Storage lainnya.
  • Ini harus dalam format VHD tetap. VHD atau VHD dinamis dalam format VHDx belum didukung di Azure. VHD dinamis akan dikonversi ke VHD statis saat Anda mengunggah VHD dengan commandlet PowerShell atau CLI
  • VHD, yang dipasang ke VM dan harus dipasang lagi di Azure ke VM juga harus dalam format VHD tetap. Baca artikel ini untuk batas ukuran disk data. VHD dinamis akan dikonversi ke VHD statis saat Anda mengunggah VHD dengan commandlet PowerShell atau CLI
  • Tambahkan akun lokal lain karena mungkin diperlukan untuk skenario penyebaran tertentu.
  • Jika gambar berisi penginstalan SAP NetWeaver dan penggantian nama host dari nama asli pada titik penyebaran Azure dimungkinkan, disarankan untuk menyalin versi terbaru DVD SAP Software Provisioning Manager ke dalam template. Ini akan memungkinkan Anda untuk dengan mudah menggunakan fungsi ganti nama yang disediakan SAP untuk menyesuaikan nama host yang diubah dan / atau mengubah SID sistem SAP dalam gambar VM yang diterapkan segera setelah salinan baru dimulai.

Windows logo. Windows

Pastikan drive D:\ tidak digunakan Atur automount disk untuk disk terlampir seperti yang dijelaskan dalam bab Mengatur automount untuk disk yang dilampirkan dalam dokumen ini.

Logo Linux. Linux

Pastikan /mnt/resource tidak digunakan dan SEMUA disk dipasang melalui uuid. Untuk disk OS, pastikan bahwa entri bootloader juga mencerminkan dudukan berbasis uuid.


  • SAP GUI (untuk tujuan administratif dan pengaturan) dapat dipasang sebelumnya dalam templat seperti itu.
  • Perangkat lunak lain yang diperlukan untuk menjalankan VM berhasil dalam skenario lintas tempat dapat dipasang selama perangkat lunak ini dapat bekerja dengan nama perubahan VM.

Jika VM disiapkan cukup untuk menjadi generik dan akhirnya terpisah dari akun/pengguna yang tidak tersedia dalam skenario penyebaran Azure yang ditargetkan, langkah persiapan terakhir untuk generalisasi gambar tersebut dilakukan.

Menggeneralisasikan komputer virtual

Windows logo. Windows

Langkah terakhir adalah masuk ke VM dengan akun Administrator. Buka Jendela Perintah Windows, sebagai admin. Buka %windir%\windows\system32\sysprep dan jalankan sysprep.exe. Jendela kecil akan muncul. Penting untuk memeriksa opsi Generalisasikan (default tidak dicentang) dan mengubah Opsi Matikan dari default 'Reboot' menjadi 'matikan'. Prosedur ini mengasumsikan bahwa proses sysprep dijalankan di tempat di OS Tamu VM. Jika Anda ingin melakukan prosedur dengan VM yang sudah berjalan di Azure, ikuti langkah-langkah yang dijelaskan dalam artikel ini.

Logo Linux. Linux

Cara merekam mesin virtual Linux yang akan digunakan sebagai templat Resource Manager


Mentransfer VM dan VHD antara lokal ke Azure

Karena mengunggah gambar dan disk VM ke Azure tidak dimungkinkan melalui portal Azure, Anda perlu menggunakan cmdlet Azure PowerShell atau CLI. Kemungkinan lain adalah penggunaan alat 'AzCopy'. Alat ini dapat menyalin VHD antara lokal dan Azure (di kedua arah). Ini juga dapat menyalin VHD antara Wilayah Azure. Lihat dokumentasi ini untuk mengunduh dan menggunakan AzCopy.

Alternatif ketiga adalah menggunakan berbagai alat berorientasi GUI pihak ketiga. Namun, pastikan alat ini mendukung Blobs Halaman Azure. Untuk tujuan kita, kita perlu menggunakan penyimpanan Azure Page Blob (perbedaannya dijelaskan dalam Memahami block blob, append blob, dan page blob. Juga alat yang disediakan oleh Azure efisien dalam mengompresi VM dan VHD, yang perlu diunggah. Ini penting karena efisiensi dalam kompresi ini mengurangi waktu unggah (yang tetap bervariasi tergantung pada tautan unggahan ke internet dari fasilitas lokal dan wilayah penyebaran Azure yang ditargetkan). Ini adalah asumsi yang adil bahwa mengunggah VM atau VHD dari lokasi Eropa ke pusat data Azure yang berbasis di AS akan memakan waktu lebih lama daripada mengunggah VM /VHD yang sama ke pusat data Azure Eropa.

Mengunggah VHD dari lokal ke Azure

Untuk mengunggah VM atau VHD yang ada dari jaringan lokal seperti VM atau VHD perlu memenuhi persyaratan seperti yang tercantum dalam bab Persiapan untuk memindahkan VM dari lokal ke Azure dengan disk non-umum dari dokumen ini.

VM seperti itu TIDAK perlu diubah dan dapat diunggah dalam keadaan dan bentuk yang ada setelah dimatikan di sisi lokal. Hal yang sama berlaku untuk VHD tambahan, yang tidak berisi sistem operasi apa pun.

Mengunggah VHD dan menjadikannya Azure Disk

Dalam hal ini kami ingin mengunggah VHD, baik dengan atau tanpa OS di dalamnya, dan memasangnya ke VM sebagai disk data atau menggunakannya sebagai disk OS. Ini adalah solusi multi-langkah

PowerShell

  • Masuk ke langganan Anda dengan Connect-AzAccount
  • Atur langganan konteks Anda dengan Set-AzContext dan parameter SubscriptionId atau SubscriptionName - lihat Set-AzContext
  • Unggah VHD dengan Add-AzVhd ke Akun Azure Storage - lihat Add-AzVhd
  • (Opsional) Buat Disk Terkelola dari VHD dengan AzDisk Baru - lihat New-AzDisk
  • Atur disk OS dari konfigurasi VM baru ke VHD atau Disk Terkelola dengan Set-AzVMOSDisk ​​- lihat Set-AzVMOSDisk
  • Buat VM baru dari konfigurasi VM dengan New-AzVM - lihat New-AzVM
  • Tambahkan disk data ke VM baru dengan Add-AzVMDataDisk ​​- lihat Add-AzVMDataDisk

Azure CLI

  • Masuk ke langganan Anda dengan login az
  • Pilih langganan Anda dengan set az account --subscription>
  • Unggah VHD dengan unggahan blob penyimpanan az - lihat Menggunakan Azure CLI dengan Azure Storage.
  • (Opsional) Buat Disk terkelola dari VHD dengan membuat disk az - lihat az disk.
  • Buat VM baru yang menentukan VHD atau Disk Terkelola yang diunggah sebagai disk OS dengan az vm create dan parameter --attach-os-disk
  • Menambahkan disk data ke VM baru dengan az vm disk attach dan parameter --new

Templat

  • Mengunggah VHD dengan PowerShell atau Azure CLI
  • (Opsional) Membuat Disk terkelola dari VHD dengan PowerShell, Azure CLI, atau portal Azure
  • Sebarkan VM dengan templat JSON yang merujuk VHD seperti yang diperlihatkan dalam contoh templat JSON ini atau menggunakan Disk Terkelola seperti yang diperlihatkan dalam contoh templat JSON ini.

Penyebaran Gambar VM

Untuk mengunggah VM atau VHD yang ada dari jaringan lokal, untuk menggunakannya sebagai gambar Azure VM seperti VM atau VHD perlu memenuhi persyaratan yang tercantum dalam bab Persiapan untuk menyebarkan VM dengan gambar khusus pelanggan untuk SAP dari dokumen ini.

Azure CLI

Templat

Mengunduh VHD atau Disk Terkelola ke lokal

Azure Infrastructure as a Service bukan jalan satu arah yang hanya dapat mengunggah VHD dan sistem SAP. Anda juga dapat memindahkan sistem SAP dari Azure ke dunia lokal.

Selama pengunduhan VHD atau Disk Terkelola tidak dapat aktif. Bahkan ketika mengunduh disk, yang dipasang ke VM, VM perlu dimatikan dan dibatalkan alokasinya. Jika Anda hanya ingin mengunduh konten database, yang kemudian harus digunakan untuk menyiapkan sistem baru di tempat dan jika dapat diterima bahwa selama waktu pengunduhan dan penyiapan sistem baru yang dapat dilakukan oleh sistem di Azure masih beroperasi, Anda dapat menghindari waktu henti yang lama dengan melakukan pencadangan basis data terkompresi ke dalam disk dan hanya mengunduh disk itu dan bukan mengunduh VM basis OS.

PowerShell

  • Mengunduh Disk Terkelola Anda terlebih dahulu perlu mendapatkan akses ke blob yang mendasari Disk Terkelola. Kemudian Anda dapat menyalin blob yang mendasarinya ke akun penyimpanan baru dan mengunduh blob dari akun penyimpanan ini.

    $access = Grant-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name> -Access Read -DurationInSecond 3600
    $key = (Get-AzStorageAccountKey -ResourceGroupName <resource group> -Name <storage account name>)[0].Value
    $destContext = (New-AzStorageContext -StorageAccountName <storage account name -StorageAccountKey $key)
    Start-AzStorageBlobCopy -AbsoluteUri $access.AccessSAS -DestContainer <container name> -DestBlob <blob name> -DestContext $destContext
    # Wait for blob copy to finish
    Get-AzStorageBlobCopyState -Container <container name> -Blob <blob name> -Context $destContext
    Save-AzVhd -SourceUri <blob in new storage account> -LocalFilePath <local file path> -StorageKey $key
    # Wait for download to finish
    Revoke-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name>
    
  • Mengunduh VHD Setelah sistem SAP dihentikan dan VM dimatikan, Anda dapat menggunakan cmdlet PowerShell Save-AzVhd pada target lokal untuk mengunduh disk VHD kembali ke dunia lokal. Untuk melakukan itu, Anda memerlukan URL VHD, yang dapat Anda temukan di 'Bagian penyimpanan' portal Azure (perlu menavigasikan ke Akun Azure Storage dan kontainer penyimpanan tempat VHD dibuat) dan Anda perlu mengetahui di mana VHD harus disalin.

    Kemudian Anda dapat memanfaatkan perintah dengan mendefinisikan parameter SourceUri sebagai URL VHD untuk diunduh dan LocalFilePath sebagai lokasi fisik VHD (termasuk namanya). Perintah bisa terlihat seperti:

    Save-AzVhd -ResourceGroupName <resource group name of storage account> -SourceUri http://<storage account name>.blob.core.windows.net/<container name>/sapidedata.vhd -LocalFilePath E:\Azure_downloads\sapidesdata.vhd
    

    Untuk detail selengkapnya tentang cmdlet Save-AzVhd, lihat Save-AzVhd.

Azure CLI

  • Mengunduh Disk Terkelola Anda terlebih dahulu perlu mendapatkan akses ke blob yang mendasari Disk Terkelola. Kemudian Anda dapat menyalin blob yang mendasarinya ke akun penyimpanan baru dan mengunduh blob dari akun penyimpanan ini.

    az disk grant-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --duration-in-seconds 3600
    az storage blob download --sas-token "<sas token>" --account-name <account name> --container-name <container name> --name <blob name> --file <local file>
    az disk revoke-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>"
    
  • Mengunduh VHD Setelah sistem SAP dihentikan dan VM dimatikan, Anda dapat menggunakan perintah Azure CLI _azure storage blob download_ pada target lokal untuk mengunduh disk VHD kembali ke dunia lokal. Untuk melakukan itu, Anda memerlukan nama dankontainer VHD, yang dapat Anda temukan di 'Bagian Storage' portal Azure (perlu menavigasikan ke Akun Azure Storage dan kontainer penyimpanan tempat VHD dibuat) dan Anda perlu tahu di mana VHD harus disalin.

    Kemudian Anda dapat memanfaatkan perintah dengan mendefinisikan blob parameter dan kontainer VHD untuk diunduh dan tujuan sebagai lokasi target fisik VHD (termasuk namanya). Perintah bisa terlihat seperti:

    az storage blob download --name <name of the VHD to download> --container-name <container of the VHD to download> --account-name <storage account name of the VHD to download> --account-key <storage account key> --file <destination of the VHD to download>
    

Mentransfer VM dan disk dalam Azure

Menyalin sistem SAP dalam Azure

Sistem SAP atau bahkan server DBMS khusus yang mendukung lapisan aplikasi SAP kemungkinan akan terdiri dari beberapa disk, yang berisi OS dengan biner atau data dan file log dari database SAP. Baik fungsionalitas Azure untuk menyalin disk maupun fungsionalitas Azure untuk menyimpan disk ke disk lokal tidak memiliki mekanisme sinkronisasi, yang memotret beberapa disk secara konsisten. Oleh karena itu, keadaan disk yang disalin atau disimpan bahkan jika yang dipasang terhadap VM yang sama akan berbeda. Ini berarti bahwa dalam kasus konkret memiliki data dan logfile yang berbeda yang terkandung dalam disk yang berbeda, database pada akhirnya tidak akan konsisten.

Kesimpulan: Untuk menyalin atau menyimpan disk, yang merupakan bagian dari konfigurasi sistem SAP, Anda perlu menghentikan sistem SAP dan juga perlu mematikan VM yang digunakan. Hanya dengan begitu Anda dapat menyalin atau mengunduh set disk untuk membuat salinan sistem SAP di Azure atau di tempat.

Disk data dapat disimpan sebagai file VHD di Akun Azure Storage dan dapat langsung dilampirkan ke mesin virtual atau digunakan sebagai gambar. Dalam hal ini, VHD disalin ke lokasi lain sebelum dilampirkan ke komputer virtual. Nama lengkap file VHD di Azure harus unik dalam Azure. Seperti yang telah disebutkan sebelumnya, nama itu adalah jenis nama tiga bagian yang terlihat seperti:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Disk data juga bisa menjadi Disk Terkelola. Dalam hal ini, Disk Terkelola digunakan untuk membuat Disk Terkelola baru sebelum dilampirkan ke komputer virtual. Nama Disk Terkelola harus unik dalam grup sumber daya.

PowerShell

Anda bisa menggunakan cmdlet Azure PowerShell untuk menyalin VHD seperti yang diperlihatkan dalam artikel ini. Untuk membuat Disk Terkelola baru, gunakan New-AzDiskConfig dan New-AzDisk seperti yang diperlihatkan dalam contoh berikut.

$config = New-AzDiskConfig -CreateOption Copy -SourceUri "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" -Location <location>
New-AzDisk -ResourceGroupName <resource group name> -DiskName <disk name> -Disk $config
Azure CLI

Anda dapat menggunakan Azure CLI untuk menyalin VHD. Untuk membuat Disk Terkelola baru, gunakan buat disk az seperti yang ditunjukkan dalam contoh berikut.

az disk create --source "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --name <disk name> --resource-group <resource group name> --location <location>
Alat Azure Storage

Edisi profesional Azure Storage Explorers dapat ditemukan di sini:

Salinan VHD itu sendiri dalam akun penyimpanan adalah sebuah proses, yang hanya membutuhkan waktu beberapa detik (mirip dengan perangkat keras SAN yang membuat rekam jepret dengan lazy copy dan copy on write). Setelah Anda memiliki salinan file VHD, Anda dapat melampirkannya ke komputer virtual atau menggunakannya sebagai gambar untuk melampirkan salinan VHD ke komputer virtual.

PowerShell
# attach a vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -VhdUri <path to vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -ManagedDiskId <managed disk id> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a copy of the vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name <disk name> -VhdUri <new path of vhd> -SourceImageUri <path to image vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption fromImage
$vm | Update-AzVM

# attach a copy of the managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$diskConfig = New-AzDiskConfig -Location $vm.Location -CreateOption Copy -SourceUri <source managed disk id>
$disk = New-AzDisk -DiskName <disk name> -Disk $diskConfig -ResourceGroupName <resource group name>
$vm = Add-AzVMDataDisk -VM $vm -Caching <caching option> -Lun <lun, for example 0> -CreateOption attach -ManagedDiskId $disk.Id
$vm | Update-AzVM
Azure CLI

# attach a vhd to a vm
az vm unmanaged-disk attach --resource-group <resource group name> --vm-name <vm name> --vhd-uri <path to vhd>

# attach a managed disk to a vm
az vm disk attach --resource-group <resource group name> --vm-name <vm name> --disk <managed disk id>

# attach a copy of the vhd to a vm
# this scenario is currently not possible with Azure CLI. A workaround is to manually copy the vhd to the destination.

# attach a copy of a managed disk to a vm
az disk create --name <new disk name> --resource-group <resource group name> --location <location of target virtual machine> --source <source managed disk id>
az vm disk attach --disk <new disk name or managed disk id> --resource-group <resource group name> --vm-name <vm name> --caching <caching option> --lun <lun, for example 0>

Menyalin blob antar Akun Azure Storage

Tugas ini tidak dapat dilakukan di portal Azure. Anda dapat menggunakan cmdlet Azure PowerShell, Azure CLI, atau browser penyimpanan pihak ketiga. Cmdlet PowerShell atau perintah CLI dapat membuat dan mengelola blob, yang mencakup kemampuan untuk menyalin blob secara asinkron di seluruh Akun Azure Storage dan di seluruh wilayah dalam langganan Azure.

PowerShell

Anda juga dapat menyalin VHD antar langganan. Untuk mengetahui informasi selengkapnya, baca artikel ini.

Alur dasar logika cmdlet PowerShell terlihat seperti ini:

  • Buat konteks akun penyimpanan untuk akun penyimpanan sumber dengan New-AzStorageContext - lihat New-AzStorageContext
  • Buat konteks akun penyimpanan untuk akun penyimpanan target dengan New-AzStorageContext - lihat New-AzStorageContext
  • Mulai salinan dengan
Start-AzStorageBlobCopy -SrcBlob <source blob name> -SrcContainer <source container name> -SrcContext <variable containing context of source storage account> -DestBlob <target blob name> -DestContainer <target container name> -DestContext <variable containing context of target storage account>
  • Periksa status salinan dalam loop dengan
Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>
  • Pasang VHD baru ke komputer virtual seperti yang dijelaskan di atas.

Misalnya lihat artikel ini.

Azure CLI
  • Mulai salinan dengan
az storage blob copy start --source-blob <source blob name> --source-container <source container name> --source-account-name <source storage account name> --source-account-key <source storage account key> --destination-container <target container name> --destination-blob <target blob name> --account-name <target storage account name> --account-key <target storage account name>
  • Periksa status jika salinan masih dalam loop dengan
az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>
  • Pasang VHD baru ke komputer virtual seperti yang dijelaskan di atas.

Penanganan Cakram

Struktur VM/disk untuk penyebaran SAP

Idealnya penanganan struktur VM dan disk terkait harus sederhana. Dalam penginstalan lokal, pelanggan mengembangkan banyak cara untuk menyusun penginstalan server.

  • Satu disk dasar, yang berisi OS dan semua biner DBMS dan / atau SAP. Sejak Maret 2015, disk ini dapat berukuran hingga 1 TB alih-alih pembatasan sebelumnya yang membatasinya hingga 127 GB.
  • Satu atau beberapa disk, yang berisi file log DBMS dari database SAP dan file log area penyimpanan temp DBMS (jika DBMS mendukung ini). Jika persyaratan IOPS log database tinggi, Anda perlu menghapus beberapa disk untuk mencapai volume IOPS yang diperlukan.
  • Sejumlah disk yang berisi satu atau dua file database dari database SAP dan juga file data DBMS (jika DBMS mendukung ini).

Konfigurasi Referensi Azure IaaS VM untuk SAP


Windows logo. Windows

Dengan banyak pelanggan kami melihat konfigurasi ketika misalnya, biner SAP dan DBMS tidak dipasang pada c:\ drive tempat OS dipasang. Ada berbagai alasan untuk ini, tetapi ketika kami kembali ke root, biasanya drive kecil dan peningkatan OS membutuhkan ruang tambahan 10-15 tahun yang lalu. Kedua kondisi tersebut tidak lagi terlalu sering berlaku hari ini. Hari ini c:\ drive dapat dipetakan pada disk volume besar atau VM. Untuk menjaga struktur penyebaran tetap sederhana, disarankan untuk mengikuti pola penyebaran berikut untuk sistem SAP NetWeaver di Azure

Pagefile sistem operasi Windows harus berada di D: drive (disk tidak persisten)

Logo Linux. Linux

Tempatkan swapfile Linux di bawah /mnt /mnt/resource di Linux seperti yang dijelaskan dalam artikel ini. File swap dapat dikonfigurasikan dalam file konfigurasi Agen Linux /etc/waagent.conf. Tambahkan atau ubah pengaturan berikut:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Untuk mengaktifkan perubahan, Anda perlu menghidupkan ulang Agen Linux dengan

sudo service waagent restart

Membaca SAP Note 1597355 untuk detail lebih lanjut tentang ukuran file pertukaran yang direkomendasikan


Jumlah disk yang digunakan untuk file data DBMS dan jenis Microsoft Azure Storage disk ini dihosting harus ditentukan oleh persyaratan IOPS dan latensi yang diperlukan. Kuota yang tepat dijelaskan dalam artikel ini (Linux) dan artikel ini (Windows).

Pengalaman penyebaran SAP selama dua tahun terakhir mengajarkan kami beberapa pelajaran, yang dapat diringkas sebagai:

  • Lalu lintas IOPS ke file data yang berbeda tidak selalu sama karena sistem pelanggan yang ada mungkin memiliki file data berukuran berbeda yang mewakili database SAP mereka. Akibatnya ternyata lebih baik menggunakan konfigurasi RAID melalui beberapa disk untuk menempatkan file data LUNs yang diukir dari file tersebut. Ada situasi, terutama dengan Standard Storage Azure yang tingkat IOPS mencapai kuota satu disk terhadap log transaksi DBMS. Dalam skenario seperti itu, penggunaan Penyimpanan Premium direkomendasikan atau secara alternatif menggabungkan beberapa disk Standard Storage dengan garis perangkat lunak.

Windows logo. Windows

Logo Linux. Linux


  • Penyimpanan Premium menunjukkan kinerja yang lebih baik yang signifikan, terutama untuk penulisan log transaksi penting. Untuk skenario SAP yang diharapkan dapat memberikan produksi seperti kinerja, sangat disarankan untuk menggunakan VM-Series dapat memanfaatkan Penyimpanan Premium Azure.

Perlu diingat bahwa disk, yang berisi OS, dan seperti yang kami rekomendasikan, biner SAP dan database (basis VM) juga, tidak lagi terbatas pada 127 GB. Sekarang dapat memiliki ukuran hingga 1 TB. Ini harus cukup ruang untuk menyimpan semua file yang diperlukan termasuk, misalnya, log pekerjaan batch SAP.

Untuk saran lebih lanjut dan detail lebih lanjut, khusus untuk DBMS VM, lihat Panduan Penggunaan DBMS

Penanganan Cakram

Dalam kebanyakan skenario, Anda perlu membuat disk tambahan untuk menyebarkan database SAP ke dalam VM. Kami berbicara tentang pertimbangan jumlah disk dalam struktur bab VM/disk untuk penyebaran SAP dari dokumen ini. portal Azure memungkinkan untuk melampirkan dan melepaskan disk setelah VM dasar disebarkan. Disk dapat dilampirkan /dilepas ketika VM sedang berjalan dan berjalan serta ketika dihentikan. Saat melampirkan disk, portal Azure menawarkan untuk melampirkan disk kosong atau disk yang ada, yang pada saat ini tidak terpasang ke VM lain.

Catatan: Disk hanya dapat dilampirkan ke satu VM pada waktu tertentu.

Pasang / lepaskan disk dengan Standard Storage Azure

Selama penyebaran mesin virtual baru, Anda dapat memutuskan apakah Anda ingin menggunakan Disk Terkelola atau menempatkan disk Anda di Akun Azure Storage. Jika Anda ingin menggunakan Penyimpanan Premium, sebaiknya gunakan Disk Terkelola.

Selanjutnya, Anda perlu memutuskan apakah Anda ingin membuat disk baru dan kosong atau apakah Anda ingin memilih disk yang ada yang diunggah sebelumnya dan harus dilampirkan ke VM sekarang.

PENTING: Anda TIDAK ingin menggunakan Host Penembolokan dengan Azure Standard Storage. Anda harus meninggalkan preferensi Host Cache di default NONE. Dengan Penyimpanan Premium Azure, Anda harus mengaktifkan Read Penembolokan jika karakteristik I/O sebagian besar dibaca seperti lalu lintas I/O umum terhadap file data database. Dalam kasus file log transaksi database, tidak ada penembolokan yang direkomendasikan.


Windows logo. Windows

Cara melampirkan disk data di portal Azure

Jika disk terpasang, Anda perlu masuk ke VM untuk membuka Pengelola Disk Windows. Jika automount tidak diaktifkan seperti yang direkomendasikan dalam bab Pengaturan automount untuk disk terlampir, volume yang baru terpasang perlu diambil secara online dan diinisialisasi.

Logo Linux. Linux

Jika disk terlampir, Anda perlu masuk ke VM dan menginisialisasi disk seperti yang dijelaskan dalam artikel ini


Jika disk baru adalah disk kosong, Anda juga perlu memformat disk tersebut. Untuk pemformatan, terutama untuk data DBMS dan file log rekomendasi yang sama seperti untuk penyebaran bare-metal DBMS berlaku.

Akun Azure Storage tidak menyediakan sumber daya tak terbatas dalam hal volume I/O, IOPS, dan volume data. Biasanya DBMS VM paling terpengaruh oleh ini. Mungkin yang terbaik adalah menggunakan Akun Azure Storage terpisah untuk setiap VM jika Anda memiliki beberapa VM volume I/O tinggi untuk digunakan agar tetap berada dalam batas volume Akun Azure Storage. Jika tidak, Anda perlu melihat bagaimana Anda dapat menyeimbangkan VM ini di antara akun Azure Storage yang berbeda tanpa mencapai batas setiap Akun Azure Storage tunggal. Rincian lebih lanjut dibahas dalam Panduan Penyebaran DBMS. Anda juga harus mengingat keterbatasan ini untuk VM server aplikasi SAP murni atau VM lainnya, yang akhirnya mungkin memerlukan VHD tambahan. Pembatasan ini tidak berlaku jika Anda menggunakan Disk Terkelola. Jika Anda ingin menggunakan Azure Storage Premium, sebaiknya gunakan Disk Terkelola.

Topik lain, yang relevan untuk Akun Azure Storage adalah apakah VHD di Akun Azure Storage mendapatkan Geo-direplikasi. Replikasi geografis diaktifkan atau dinonaktifkan pada tingkat Akun Azure Storage dan bukan pada tingkat VM. Jika replikasi geografis diaktifkan, VHD dalam Akun Azure Storage akan direplikasi ke pusat data Azure lain dalam wilayah yang sama. Sebelum memutuskan hal ini, Anda harus memikirkan pembatasan berikut:

Azure Geo-replikasi bekerja secara lokal pada setiap VHD dalam VM dan tidak mereplikasi I/Os dalam urutan kronologis di beberapa VHD dalam VM. Oleh karena itu, VHD yang mewakili VM dasar serta VHD tambahan yang melekat pada VM direplikasi independen satu sama lain. Ini berarti tidak ada sinkronisasi antara perubahan dalam VHD yang berbeda. Fakta bahwa I/Os direplikasi secara independen dari urutan di mana mereka ditulis berarti bahwa geo-replikasi tidak bernilai untuk server database yang memiliki database mereka didistribusikan melalui beberapa VHD. Selain DBMS, mungkin juga ada aplikasi lain yang proses menulis atau memanipulasi data dalam VHD yang berbeda dan yang penting untuk menjaga urutan perubahan. Jika itu adalah persyaratan, replikasi geografis di Azure tidak boleh diaktifkan. Tergantung pada apakah Anda membutuhkan atau menginginkan replikasi geografis untuk satu set VM, tetapi tidak untuk set lain, Anda sudah dapat mengkategorikan VM dan VHD terkait ke dalam Akun Penyimpanan yang berbeda yang mengaktifkan atau menonaktifkan replikasi geografis.

Menyetel otomatis untuk disk terpasang


Windows logo. Windows

Untuk VM, yang dibuat dari Gambar atau Disk sendiri, perlu untuk memeriksa dan mungkin mengatur parameter automount. Pengaturan parameter ini akan memungkinkan VM setelah restart atau pemindahan ulang di Azure untuk memasang drive yang terpasang/dipasang lagi secara otomatis. Parameter diatur untuk gambar yang disediakan oleh Microsoft di Azure Marketplace.

Untuk mengatur automount, periksa dokumentasi perintah-baris yang dapat dieksekusi di diskpart.exe sini:

Jendela baris perintah Windows harus dibuka sebagai admin.

Jika disk terpasang, Anda perlu masuk ke VM untuk membuka Pengelola Disk Windows. Jika automount tidak diaktifkan seperti yang direkomendasikan dalam bab Pengaturan automount untuk disk terlampir,volume yang baru terlampir perlu diambil secara online dan diinisialisasi.

Logo Linux. Linux

Anda perlu menginisialisasi disk kosong yang baru dilampirkan seperti yang dijelaskan dalam artikel ini. Anda juga perlu menambahkan disk baru ke /etc/fstab.


Penyebaran Akhir

Untuk penyebaran akhir dan langkah-langkah tepat, terutama penyebaran Ekstensi Azure untuk SAP, lihat Panduan Penerapan.

Mengakses sistem SAP yang berjalan dalam Azure VMs

Untuk skenario di mana Anda ingin terhubung ke sistem SAP di internet publik menggunakan SAP GUI, prosedur berikut perlu diterapkan.

Nantinya dalam dokumen kita akan membahas skenario utama lainnya, menghubungkan ke sistem SAP dalam penyebaran lintas tempat, yang memiliki koneksi situs ke situs (terowongan VPN) atau koneksi Azure ExpressRoute antara sistem lokal dan sistem Azure.

Akses Jarak Jauh ke sistem SAP

Dengan Azure Resource Manager, tidak ada titik akhir default lagi seperti di model klasik sebelumnya. Semua port Azure Resource Manager VM terbuka selama:

  1. Tidak ada Kelompok Keamanan Jaringan yang didefinisikan untuk subjaringan atau antarmuka jaringan. Lalu lintas jaringan ke Azure VM dapat diamankan melalui apa yang disebut "Kelompok Keamanan Jaringan". Untuk informasi selengkapnya, lihat Apa itu Kelompok Keamanan Jaringan (NSG)?
  2. Tidak ada Azure Load Balancer yang didefinisikan untuk antarmuka jaringan

Lihat perbedaan arsitektur antara model klasik dan ARM seperti yang dijelaskan dalam artikel ini.

Konfigurasi sistem SAP dan konektivitas SAP GUI melalui internet

Lihat artikel ini, yang menjelaskan detail topik ini: Koneksi SAP GUI ditutup saat membuat sambungan ke sistem SAP di Azure

Mengubah Pengaturan Firewall dalam VM

Mungkin perlu untuk mengkonfigurasi firewall pada mesin virtual Anda untuk memungkinkan lalu lintas masuk ke sistem SAP Anda.


Windows logo. Windows

Secara default, Windows Firewall dalam VM yang diterapkan Azure diaktifkan. Anda sekarang perlu mengizinkan Port SAP dibuka, jika tidak SAP GUI tidak akan dapat terhubung. Untuk melakukan ini:

  • Buka Panel Kontrol\Sistem dan Keamanan\Firewall Windows ke Setelan Tingkat Lanjut.
  • Sekarang klik kanan pada Aturan Masuk dan pilih Aturan Baru.
  • Dalam Wizard berikut ini memilih untuk membuat aturan Port baru.
  • Di langkah panduan berikutnya, biarkan pengaturan di TCP dan ketik nomor port yang ingin Anda buka. Karena ID instans SAP kami adalah 00, kami mengambil 3200. Jika instans Anda memiliki nomor instans yang berbeda, port yang Anda tentukan sebelumnya berdasarkan nomor instans harus dibuka.
  • Di bagian wizard berikutnya, Anda harus membiarkan item Perbolehkan Koneksi dicentang.
  • Di langkah wizard berikutnya, Anda perlu menentukan apakah aturan tersebut berlaku untuk jaringan Domain, Privat, dan Publik. Sesuaikan jika perlu dengan kebutuhan Anda. Namun, terhubung dengan SAP GUI dari luar melalui jaringan publik, Anda harus menerapkan aturan ke jaringan publik.
  • Di langkah terakhir wizard, beri nama aturan dan simpan dengan menekan Selesai.

Aturan menjadi efektif segera.

Definisi aturan port

Logo Linux. Linux

Gambar Linux di Azure Marketplace tidak mengaktifkan firewall iptable secara default dan koneksi ke sistem SAP Anda harus berfungsi. Jika Anda mengaktifkan iptable atau firewall lain, lihat dokumentasi iptable atau firewall yang digunakan untuk memungkinkan lalu lintas tcp masuk ke port 32xx (di mana xx adalah nomor sistem sistem SAP Anda).


Rekomendasi keamanan

SAP GUI tidak segera terhubung ke salah satu instance SAP (port 32xx) yang berjalan, tetapi pertama-tama terhubung melalui port yang dibuka ke proses server pesan SAP (port 36xx). Di masa lalu, port yang sama digunakan oleh server pesan untuk komunikasi internal ke instans aplikasi. Untuk mencegah server aplikasi lokal berkomunikasi secara tidak sengaja dengan server pesan di Azure, port komunikasi internal dapat diubah. Sangat disarankan untuk mengubah komunikasi internal antara server pesan SAP dan instans aplikasinya ke nomor port yang berbeda pada sistem yang telah dikloning dari sistem lokal, seperti kloning pengembangan untuk pengujian proyek dll. Ini dapat dilakukan dengan parameter profil default:

rdisp/msserv_internal

seperti yang didokumentasikan di Pengaturan Keamanan untuk Server Pesan SAP

VM Tunggal dengan skenario demo /pelatihan SAP NetWeaver

Menjalankan sistem demo VM SAP tunggal dengan nama VM yang sama, diisolasi di Azure Cloud Services

Dalam skenario ini kami menerapkan skenario sistem pelatihan/demo yang khas yang skenario pelatihan/demo lengkap terkandung dalam satu VM. Kami berasumsi bahwa penyebaran dilakukan melalui templat gambar VM. Kami juga berasumsi bahwa kelipatan dari demo/pelatihan ini VM perlu disebarkan dengan VM yang memiliki nama yang sama. Seluruh sistem pelatihan tidak memiliki konektivitas ke aset lokal Anda dan berlawanan dengan penyebaran hibrid.

Asumsinya adalah Anda membuat Gambar VM seperti yang dijelaskan di beberapa bagian bab Mempersiapkan VM dengan SAP untuk Azure dalam dokumen ini.

Urutan peristiwa untuk mengimplementasikan skenario terlihat seperti ini:

PowerShell
  • Membuat grup sumber daya baru untuk setiap lanskap pelatihan/demo
$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"
  • Membuat akun penyimpanan baru jika Anda tidak ingin menggunakan Disk Terkelola
$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"
  • Buat jaringan virtual baru untuk setiap lanskap pelatihan/demo untuk memungkinkan penggunaan nama host dan alamat IP yang sama. Jaringan virtual dilindungi oleh Kelompok Keamanan Jaringan yang hanya memungkinkan lalu lintas ke port 3389 untuk mengaktifkan akses Desktop Jauh dan port 22 untuk SSH.
# Create a new Virtual Network
$rdpRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGRDP -Protocol * -SourcePortRange * -DestinationPortRange 3389 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 100
$sshRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGSSH -Protocol * -SourcePortRange * -DestinationPortRange 22 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 101
$nsg = New-AzNetworkSecurityGroup -Name SAPERPDemoNSG -ResourceGroupName $rgName -Location  "North Europe" -SecurityRules $rdpRule,$sshRule

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix  10.0.1.0/24 -NetworkSecurityGroup $nsg
$vnet = New-AzVirtualNetwork -Name SAPERPDemoVNet -ResourceGroupName $rgName -Location "North Europe"  -AddressPrefix 10.0.1.0/24 -Subnet $subnetConfig
  • Membuat alamat IP publik baru yang dapat digunakan untuk mengakses komputer virtual dari internet
# Create a public IP address with a DNS name
$pip = New-AzPublicIpAddress -Name SAPERPDemoPIP -ResourceGroupName $rgName -Location "North Europe" -DomainNameLabel $rgName.ToLower() -AllocationMethod Dynamic
  • Membuat antarmuka jaringan baru untuk mesin virtual
# Create a new Network Interface
$nic = New-AzNetworkInterface -Name SAPERPDemoNIC -ResourceGroupName $rgName -Location "North Europe" -Subnet $vnet.Subnets[0] -PublicIpAddress $pip
  • Membuat komputer virtual. Untuk skenario ini, setiap VM akan memiliki nama yang sama. SAP SID dari contoh SAP NetWeaver di VM tersebut juga akan sama. Dalam Azure Resource Group, nama VM harus unik, tetapi di Grup Sumber Daya Azure yang berbeda Anda dapat menjalankan VM dengan nama yang sama. Akun 'Administrator default Windows atau 'root' untuk Linux tidak valid. Oleh karena itu, nama pengguna admin baru perlu didefinisikan bersama dengan kata sandi. Ukuran VM juga perlu didefinisikan.
#####
# Create a new virtual machine with an official image from the Azure Marketplace
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

# select image
$vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2012-R2-Datacenter" -Version "latest"
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "SUSE" -Offer "SLES-SAP" -Skus "12-SP1" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "RedHat" -Offer "RHEL" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "Oracle" -Offer "Oracle-Linux" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig
#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$diskName="osfromimage"
$osDiskUri=$account.PrimaryEndpoints.Blob.ToString() + "vhds/" + $diskName  + ".vhd"

$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Windows
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Linux
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig
#####
# Create a new virtual machine with a Managed Disk Image
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMSourceImage -VM $vmconfig -Id <Id of Managed Disk Image>
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig
  • Secara opsional tambahkan disk tambahan dan pulihkan isi yang diperlukan. Semua nama blob (URL ke blob) harus unik dalam Azure.
# Optional: Attach additional VHD data disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
$dataDiskUri = $account.PrimaryEndpoints.Blob.ToString() + "vhds/datadisk.vhd"
Add-AzVMDataDisk -VM $vm -Name datadisk -VhdUri $dataDiskUri -DiskSizeInGB 1023 -CreateOption empty | Update-AzVM

# Optional: Attach additional Managed Disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
Add-AzVMDataDisk -VM $vm -Name datadisk -DiskSizeInGB 1023 -CreateOption empty -Lun 0 | Update-AzVM
CLI

Contoh kode berikut dapat digunakan di Linux. Untuk Windows, gunakan PowerShell seperti yang dijelaskan di atas atau sesuaikan contoh untuk menggunakan %rgName% bukan $rgName dan atur variabel lingkungan menggunakan setperintah Windows.

  • Membuat grup sumber daya baru untuk setiap lanskap pelatihan/demo
rgName=SAPERPDemo1
rgNameLower=saperpdemo1
az group create --name $rgName --location "North Europe"
  • Buat akun penyimpanan baru
az storage account create --resource-group $rgName --location "North Europe" --kind Storage --sku Standard_LRS --name $rgNameLower
  • Buat jaringan virtual baru untuk setiap lanskap pelatihan/demo untuk memungkinkan penggunaan nama host dan alamat IP yang sama. Jaringan virtual dilindungi oleh Kelompok Keamanan Jaringan yang hanya memungkinkan lalu lintas ke port 3389 untuk mengaktifkan akses Desktop Jauh dan port 22 untuk SSH.
az network nsg create --resource-group $rgName --location "North Europe" --name SAPERPDemoNSG
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGRDP --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 3389 --access Allow --priority 100 --direction Inbound
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGSSH --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 22 --access Allow --priority 101 --direction Inbound

az network vnet create --resource-group $rgName --name SAPERPDemoVNet --location "North Europe" --address-prefixes 10.0.1.0/24
az network vnet subnet create --resource-group $rgName --vnet-name SAPERPDemoVNet --name Subnet1 --address-prefix 10.0.1.0/24 --network-security-group SAPERPDemoNSG
  • Membuat alamat IP publik baru yang dapat digunakan untuk mengakses komputer virtual dari internet
az network public-ip create --resource-group $rgName --name SAPERPDemoPIP --location "North Europe" --dns-name $rgNameLower --allocation-method Dynamic
  • Membuat antarmuka jaringan baru untuk mesin virtual
az network nic create --resource-group $rgName --location "North Europe" --name SAPERPDemoNIC --public-ip-address SAPERPDemoPIP --subnet Subnet1 --vnet-name SAPERPDemoVNet
  • Membuat komputer virtual. Untuk skenario ini, setiap VM akan memiliki nama yang sama. SAP SID dari contoh SAP NetWeaver di VM tersebut juga akan sama. Dalam Azure Resource Group, nama VM harus unik, tetapi di Grup Sumber Daya Azure yang berbeda Anda dapat menjalankan VM dengan nama yang sama. Akun 'Administrator default Windows atau 'root' untuk Linux tidak valid. Oleh karena itu, nama pengguna admin baru perlu didefinisikan bersama dengan kata sandi. Ukuran VM juga perlu didefinisikan.
#####
# Create virtual machines using storage accounts
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password

#####
# Create virtual machines using Managed Disks
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Windows --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Linux --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd> --authentication-type password

#####
# Create a new virtual machine with a Managed Disk Image
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id> --authentication-type password
  • Secara opsional tambahkan disk tambahan dan pulihkan isi yang diperlukan. Semua nama blob (URL ke blob) harus unik dalam Azure.
# Optional: Attach additional VHD data disks
az vm unmanaged-disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --vhd-uri https://$rgNameLower.blob.core.windows.net/vhds/data.vhd  --new

# Optional: Attach additional Managed Disks
az vm disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --disk datadisk --new
Templat

Anda dapat menggunakan contoh templat di repositori Azure-quickstart-templates di GitHub.

Mengimplementasikan sekumpulan VM yang berkomunikasi dalam Azure

Skenario non-hibrid ini adalah skenario khas untuk tujuan pelatihan dan demo ketika perangkat lunak yang mewakili skenario demo/pelatihan tersebar di beberapa VM. Komponen yang berbeda yang dipasang di VM yang berbeda perlu berkomunikasi satu sama lain. Sekali lagi, dalam skenario ini tidak diperlukan komunikasi jaringan lokal atau skenario lintas lokasi.

Skenario ini adalah perpanjangan dari ipenginstalan yang dijelaskan dalam bab VM Tunggal dengan skenario demo/pelatihan SAP NetWeaver dari dokumen ini. Dalam hal ini, lebih banyak komputer virtual akan ditambahkan ke grup sumber daya yang ada. Dalam contoh berikut, lanskap pelatihan terdiri dari SAP ASCS/SCS VM, VM yang menjalankan DBMS, dan contoh Server Aplikasi SAP VM.

Sebelum Anda membuat skenario ini, Anda perlu memikirkan pengaturan dasar seperti yang sudah dilakukan dalam skenario sebelumnya.

Penamaan Grup Sumber Daya dan Komputer Virtual

Semua nama grup sumber daya harus unik. Kembangkan skema penamaan Anda sendiri dari sumber daya Anda, seperti <rg-name> akhiran.

Nama komputer virtual - harus unik dalam grup sumber daya.

Menyetel Jaringan untuk komunikasi antara VM yang berbeda

Kumpulan VM dalam Jaringan Virtual Azure

Untuk mencegah tabrakan penamaan dengan klon lanskap pelatihan/demo yang sama, Anda perlu membuat Azure Virtual Network untuk setiap lanskap. Resolusi nama DNS akan disediakan oleh Azure atau Anda dapat mengonfigurasikan server DNS Anda sendiri di luar Azure (tidak untuk dibahas lebih lanjut di sini). Dalam skenario ini, kami tidak mengonfigurasikan DNS kami sendiri. Untuk semua mesin virtual di dalam satu Azure Virtual Network, komunikasi melalui nama host akan diaktifkan.

Alasan untuk memisahkan pelatihan atau lanskap demo oleh jaringan virtual dan tidak hanya kelompok sumber daya yang dapat:

  • Lanskap SAP sebagai pengaturan membutuhkan AD/OpenLDAP sendiri dan Server Domain harus menjadi bagian dari masing-masing lanskap.
  • Lanskap SAP sebagaimana diatur memiliki komponen yang perlu bekerja dengan alamat IP tetap.

Detail selengkapnya tentang Azure Virtual Networks dan cara menentukannya dapat ditemukan di artikel ini.

Menyebarkan SAP VM dengan konektivitas jaringan perusahaan (Lintas Lokasi)

Anda menjalankan lanskap SAP dan ingin membagi penyebaran antara bare-metal untuk server DBMS kelas atas, lingkungan virtual lokal untuk lapisan aplikasi, dan sistem SAP 2-Tingkat yang dikonfigurasikan lebih kecil dan Azure IaaS. Asumsi dasarnya adalah bahwa sistem SAP dalam satu lanskap SAP perlu berkomunikasi satu sama lain dan dengan banyak komponen perangkat lunak lain yang diterapkan di perusahaan, terlepas dari bentuk penyebaran mereka. Seharusnya juga tidak ada perbedaan yang diperkenalkan oleh formulir penyebaran untuk pengguna akhir yang terhubung dengan SAP GUI atau antarmuka lainnya. Kondisi ini hanya dapat dipenuhi ketika kami memiliki Layanan Active Directory/OpenLDAP dan DNS lokal yang diperluas ke sistem Azure melalui konektivitas situs ke situs /multi-situs atau koneksi privat seperti Azure ExpressRoute.

Skenario lanskap SAP

Skenario cross-premise atau hybrid secara kasar dapat digambarkan seperti pada grafik di bawah ini:

Konektivitas situs ke situs antara aset lokal dan Azure

Persyaratan minimum adalah penggunaan protokol komunikasi yang aman seperti SSL / TLS untuk akses browser atau koneksi berbasis VPN untuk akses sistem ke layanan Azure. Asumsinya adalah bahwa perusahaan menangani koneksi VPN antara jaringan perusahaan mereka dan Azure secara berbeda. Beberapa perusahaan mungkin secara bebas membuka semua port. Beberapa perusahaan lain mungkin memberlakukan secara lebih khusus port mana yang perlu dibuka, dll.

Tabel di bawah ini mencantumkan port komunikasi SAP tipikal. Pada dasarnya cukup untuk membuka port gateway SAP.

Layanan Port Nama Contoh <nn> = 01 Rentang Default (min-maks) Komentar
Dispatcher sapdp<nn> lihat * 3201 3200 - 3299 SAP Dispatcher, digunakan oleh SAP GUI untuk Windows dan Java
Server pesan sapms <sid> lihat ** 3600 sapms gratis<anySID> sid = SAP-System-ID
Gateway sapgw <nn> lihat * 3301 bebas Gateway SAP, digunakan untuk komunikasi CPIC dan RFC
Router SAP sapdp99 3299 bebas Hanya CI (instans pusat) Nama layanan yang dapat ditetapkan ulang dalam /etc/services ke nilai arbitrer setelah penginstalan.

*) nn = Nomor Instans SAP

**)sid = SAP-System-ID

Informasi lebih rinci tentang port yang diperlukan untuk produk atau layanan SAP yang berbeda oleh produk SAP dapat ditemukan di sini https://scn.sap.com/docs/DOC-17124. Dengan dokumen ini, Anda harus dapat membuka port khusus di perangkat VPN yang diperlukan untuk produk dan skenario SAP tertentu.

Langkah-langkah keamanan lainnya saat menyebarkan VM dalam skenario seperti itu bisa untuk membuat Kelompok Keamanan Jaringan untuk menentukan aturan akses.

Mencetak pada printer jaringan lokal dari instans SAP di Azure

Mencetak melalui TCP/IP dalam skenario Lintas Tempat

Menyiapkan printer jaringan berbasis TCP/IP lokal Anda di Azure VM secara keseluruhan sama seperti di jaringan perusahaan Anda, dengan asumsi Anda memiliki terowongan Situs-Ke-Situs VPN atau koneksi ExpressRoute yang sudah dibuat.


Windows logo. Windows

Untuk melakukan ini:

  • Beberapa printer jaringan dilengkapi dengan wizard konfigurasi yang memudahkan untuk mengatur printer Anda di Azure VM. Jika tidak ada perangkat lunak wizard yang terdistribusi dengan printer, maka cara manual untuk menyetel printer adalah dengan membuat port printer TCP/IP baru.
  • Panel Kontrol Terbuka - > Perangkat dan Printer - Tambahkan > pencetak
  • Pilih Tambahkan printer menggunakan alamat TCP/IP atau nama host
  • Ketik alamat IP printer
  • Standar Port Printer 9100
  • Jika perlu, pasang driver printer yang sesuai secara manual.

Logo Linux. Linux

  • seperti untuk Windows ikuti saja prosedur standar untuk memasang printer jaringan
  • cukup ikuti panduan Linux publik untuk SUSE atau Red Hat dan Oracle Linux tentang cara menambahkan printer.

Pencetakan jaringan

Printer berbasis host melalui SMB (printer bersama) dalam skenario Lintas Tempat

Printer berbasis host tidak kompatibel dengan jaringan berdasarkan desain. Tetapi printer berbasis host dapat dibagi di antara komputer pada jaringan selama printer tersambung ke komputer yang menyala. Sambungkan jaringan perusahaan Anda baik Situs-Ke-Situs atau ExpressRoute dan bagikan printer lokal Anda. Protokol SMB menggunakan NetBIOS alih-alih DNS sebagai layanan nama. Nama host NetBIOS dapat berbeda dari nama host DNS. Kasus standar adalah bahwa nama host NetBIOS dan nama host DNS identik. Domain DNS tidak mungkin berada di ruang nama NetBIOS. Dengan demikian, nama host DNS yang sepenuhnya memenuhi syarat yang terdiri dari nama host DNS dan domain DNS tidak boleh digunakan di ruang nama NetBIOS.

Berbagi printer diidentifikasi dengan nama unik di jaringan:

  • Nama host dari host SMB (selalu diperlukan).
  • Nama berbagi (selalu diperlukan).
  • Nama domain jika berbagi printer tidak dalam domain yang sama dengan sistem SAP.
  • Selain itu, nama pengguna dan kata sandi mungkin diperlukan untuk mengakses berbagi printer.

Cara:


Windows logo. Windows

Bagikan printer lokal Anda. Di Azure VM, buka Windows Explorer dan ketikkan nama berbagi printer. Wizard penginstalan printer akan memandu Anda melalui proses penginstalan.

Logo Linux. Linux

Berikut adalah beberapa contoh dokumentasi tentang mengonfigurasikan printer jaringan di Linux atau menyertakan bab mengenai pencetakan di Linux. Ini akan bekerja dengan cara yang sama dalam Azure Linux VM selama VM adalah bagian dari VPN:


Printer USB (pengalihan printer)

Di Azure kemampuan Layanan Desktop Jauh untuk menyediakan pengguna akses ke perangkat printer lokal mereka dalam sesi jarak jauh tidak tersedia.


Windows logo. Windows

Rincian lebih lanjut tentang pencetakan dengan Windows dapat ditemukan di sini: https://technet.microsoft.com/library/jj590748.aspx.


Integrasi Sistem SAP Azure ke dalam Sistem Koreksi dan Transportasi (TMS) di Lintas Lokasi

Sistem Perubahan dan Transportasi SAP (TMS) perlu dikonfigurasikan untuk mengekspor dan mengimpor permintaan transportasi di seluruh sistem di lanskap. Kami berasumsi bahwa instans pengembangan sistem SAP (DEV) terletak di Azure, sedangkan jaminan kualitas (QA) dan sistem produktif (PRD) tersedia di tempat lokal. Selain itu, kami berasumsi bahwa ada direktori transportasi pusat.

Mengonfigurasikan Domain Transportasi

Konfigurasikan Domain Transportasi Anda pada sistem yang Anda tetapkan sebagai Pengendali Domain Transportasi seperti yang dijelaskan dalam Mengonfigurasikan Pengendali Domain Transportasi. Pengguna sistem TMSADM akan dibuat dan tujuan RFC yang diperlukan akan dihasilkan. Anda dapat memeriksa koneksi RFC ini menggunakan transaksi SM59. Resolusi nama host harus diaktifkan di seluruh domain transportasi Anda.

Cara:

  • Dalam skenario kami, kami memutuskan sistem QAS lokal akan menjadi pengendali domain CTS. Panggilan transaksi STMS. Kotak dialog TMS muncul. Kotak dialog Konfigurasi Domain Transportasi ditampilkan. (Kotak dialog ini hanya muncul jika Anda belum mengonfigurasikan domain transportasi.)
  • Pastikan bahwa TMSADM pengguna yang dibuat secara otomatis diotorisasi (SM59 - > ABAP Connection - > TMSADM@E61. DOMAIN_E61 - > Rincian - > Utilitas (M) - > Tes Otorisasi). Layar awal transaksi STMS harus menunjukkan bahwa Sistem SAP ini sekarang berfungsi sebagai pengendali domain transportasi seperti yang ditunjukkan di sini:

Layar awal transaksi STMS pada pengendali domain

Menyertakan Sistem SAP di Domain Transport

Urutan menyertakan sistem SAP di domain transportasi terlihat sebagai berikut:

  • Pada sistem DEV di Azure, buka sistem transportasi (Klien 000) dan panggil STMS transaksi. Pilih Konfigurasi Lain dari kotak dialog dan lanjutkan dengan Sertakan Sistem di Domain. Tentukan Pengendali Domain sebagai host target (Menyertakan Sistem SAP di Domain Transportasi). Sistem sekarang menunggu untuk dimasukkan ke dalam domain transportasi.
  • Untuk alasan keamanan, Anda kemudian harus kembali ke pengendali domain untuk mengonfirmasi permintaan Anda. Pilih Gambaran Umum Sistem dan Setujui sistem tunggu. Kemudian konfirmasikan perintah dan konfigurasi akan didistribusikan.

Sistem SAP ini sekarang berisi informasi yang diperlukan tentang semua sistem SAP lainnya di domain transportasi. Pada saat yang sama, data alamat sistem SAP baru dikirim ke semua sistem SAP lainnya, dan sistem SAP dimasukkan ke dalam profil transportasi program kontrol transportasi. Periksa apakah RFC dan akses ke direktori transpotasi domain berfungsi.

Lanjutkan dengan konfigurasi sistem transportasi Anda seperti biasa seperti yang dijelaskan dalam dokumentasi Perubahan dan Sistem Transportasi.

Cara:

  • Pastikan STMS lokal Anda dikonfigurasikan dengan benar.
  • Pastikan nama host Pengendali Domain Transportasi dapat diselesaikan dengan mesin virtual Anda di Azure dan vice visa.
  • Transaksi panggilan STMS - > Konfigurasi Lain - Sertakan Sistem dalam > Domain.
  • Mengonfirmasikan koneksi dalam sistem TMS lokal.
  • Mengonfigurasikan rute transportasi, grup, dan lapisan seperti biasa.

Dalam skenario lintas lokasi yang tersambung dari situs ke situs, latensi antara lokal dan Azure masih bisa menjadi substansial. Jika kita mengikuti urutan pemindahan objek melalui pengembangan dan pengujian sistem ke produksi atau berpikir tentang penerapan transportasi atau paket dukungan ke sistem yang berbeda, Anda menyadari bahwa, tergantung pada lokasi direktori transportasi pusat, beberapa sistem akan mengalami latensi tinggi ketika membaca atau menulis data di direktori transport pusat. Situasi ini mirip dengan konfigurasi lanskap SAP ketika sistem yang berbeda tersebar melalui pusat data yang berbeda dengan jarak yang substansial antara pusat data.

Untuk mengatasi latensi tersebut dan meminta sistem bekerja cepat dalam membaca atau menulis ke atau dari direktori transportasi, Anda dapat mengatur dua domain transportasi STMS (satu untuk lokal dan satu dengan sistem di Azure dan menautkan domain transportasi. Periksa dokumentasi, yang menjelaskan prinsip-prinsip di balik konsep ini dalam SAP TMS.

Cara:

Lalu lintas RFC antara instans SAP yang terletak di Azure dan lokal (Lintas Tempat)

Lalu lintas RFC antar sistem, yang berada di tempat lokal dan di Azure perlu berfungsi. Untuk menyiapkan transaksi panggilan koneksi SM59 dalam sistem sumber di mana Anda perlu menentukan koneksi RFC ke arah sistem target. Konfigurasi ini mirip dengan pengaturan standar Koneksi RFC.

Kami berasumsi bahwa dalam skenario lintas tempat, VM, yang menjalankan sistem SAP yang perlu berkomunikasi satu sama lain berada di domain yang sama. Oleh karena itu pengaturan koneksi RFC antara sistem SAP tidak berbeda dari langkah-langkah pengaturan dan input dalam skenario lokal.

Mengakses fileshares lokal dari instans SAP yang terletak di Azure atau sebaliknya

Instans SAP yang berlokasi di Azure perlu mengakses berbagi file, yang berada di dalam tempat perusahaan. Selain itu, instans SAP lokal perlu mengakses berbagi file, yang terletak di Azure. Untuk memfungsikan berbagi file, Anda harus mengonfigurasikan izin dan opsi berbagi pada sistem lokal. Pastikan untuk membuka port pada VPN atau koneksi ExpressRoute antara Azure dan pusat data Anda.

Dukungan

Ekstensi Azure untuk SAP

Untuk memberi umpan beberapa bagian informasi infrastruktur Azure dari sistem SAP misi penting ke instans Agen Host SAP, yang dipasang di VM, Ekstensi Azure (VM) untuk SAP perlu dipasang untuk VM yang disebarkan. Karena tuntutan SAP khusus untuk aplikasi SAP, Microsoft memutuskan untuk tidak mengimplementasikan fungsionalitas yang diperlukan secara umum ke Azure, tetapi membiarkan pelanggan menyebarkan ekstensi dan konfigurasi VM yang diperlukan ke Komputer Virtual mereka yang berjalan di Azure. Namun, penerapan dan manajemen siklus hidup Ekstensi Azure VM untuk SAP sebagian besar akan diotomatisasi oleh Azure.

Desain solusi

Solusi yang dikembangkan untuk mengaktifkan Agen Host SAP mendapatkan informasi yang diperlukan didasarkan pada arsitektur Kerangka Kerja Agen dan Ekstensi Azure VM. Ide dari kerangka kerja Azure VM Agent and Extension adalah untuk memungkinkan penginstalan aplikasi perangkat lunak yang tersedia di galeri Azure VM Extension dalam VM. Ide utama di balik konsep ini adalah untuk memungkinkan (dalam kasus seperti Azure Monitoring Extension for SAP), penyebaran fungsionalitas khusus ke dalam VM dan konfigurasi perangkat lunak tersebut pada waktu penyebaran.

'VM Azure Agent' yang memungkinkan penanganan Ekstensi VM Azure tertentu dalam VM, disuntikkan ke VM Windows secara default pada pembuatan VM di portal Azure. Dalam kasus SUSE, Red Hat atau Oracle Linux, agen VM sudah menjadi bagian dari gambar Azure Marketplace. Jika seseorang akan mengunggah VM Linux dari tempat lokal ke Azure, agen VM harus dipasang secara manual.

Blok penyusun dasar solusi untuk memberikan informasi infrastruktur Azure kepada agen SAP Host di Azure terlihat seperti ini:

Komponen Microsoft Azure Extension

Seperti yang ditunjukkan pada diagram blok di atas, salah satu bagian solusi dihosting di Azure VM Image dan Azure Extension Gallery, yang merupakan repositori yang direplikasi secara global yang dikelola oleh Azure Operations. Adalah tanggung jawab tim gabungan SAP / MS yang bekerja pada implementasi Azure SAP untuk bekerja dengan Operasi Azure untuk menerbitkan versi baru Ekstensi untuk SAP.

Saat Anda menggunakan Windows VM baru, Azure VM Agent secara otomatis ditambahkan ke dalam VM. Fungsi agen ini adalah untuk mengoordinasikan pemuatan dan konfigurasi Ekstensi Azure VM. Untuk VM Linux, Azure VM Agent sudah menjadi bagian dari gambar OS Azure Marketplace.

Namun, ada langkah yang masih perlu dijalankan oleh pelanggan. Ini adalah pengaktifkan dan konfigurasi kumpulan performa. Proses yang terkait dengan konfigurasi diotomatisasi oleh skrip PowerShell atau perintah CLI. Skrip PowerShell dapat diunduh di Pusat Skrip Microsoft Azure seperti yang dijelaskan dalam Panduan Penyebaran.

Arsitektur keseluruhan ekstensi Azure untuk SAP terlihat seperti:

Azure extension for SAP

Untuk cara penggunaan cmdlet atau perintah CLI PowerShell ini selama penyebaran, ikuti instruksi yang diberikan dalam Panduan Penyebaran.

Integrasi instans SAP yang berlokasi di Azure ke SAProuter

Instans SAP yang berjalan di Azure juga harus dapat diakses dari SAProuter.

Koneksi Jaringan SAP-Router

SAProuter mengaktifkan komunikasi TCP/IP antara sistem yang berpartisipasi jika tidak ada koneksi IP langsung. Ini memberikan keuntungan bahwa tidak ada koneksi end-to-end antara mitra komunikasi yang diperlukan pada tingkat jaringan. SAProuter mendengarkan di port 3299 secara default. Untuk menghubungkan instans SAP melalui SAProuter, Anda perlu memberikan untai (karakter) SAProuter dan nama host dengan upaya untuk tersambung.

SAP NetWeaver AS Java

Sejauh ini fokus dokumen adalah SAP NetWeaver secara umum atau tumpukan ABAP SAP NetWeaver. Di bagian kecil ini, pertimbangan khusus untuk tumpukan SAP Java tercantum. Salah satu aplikasi berbasis eksklusif SAP NetWeaver Java yang paling penting adalah SAP Enterprise Portal. Aplikasi berbasis SAP NetWeaver lainnya seperti SAP PI dan SAP Solution Manager menggunakan tumpukan SAP NetWeaver ABAP dan Java. Oleh karena itu, tentu juga ada kebutuhan untuk mempertimbangkan aspek spesifik yang terkait dengan tumpukan SAP NetWeaver Java.

Portal Perusahaan SAP

Penyetelan Portal SAP di Azure Virtual Machine tidak berbeda dari penginstalan di tempat jika Anda menerapkan dalam skenario lintas tempat. Karena DNS dilakukan oleh lokal, pengaturan port dari masing-masing instans dapat dilakukan sebagai dikonfigurasikan secara lokal. Rekomendasi dan batasan yang dijelaskan dalam dokumen ini sejauh ini berlaku untuk aplikasi seperti SAP Enterprise Portal atau SAP NetWeaver Java stack secara umum.

Portal SAP Terbuka

Skenario penyebaran khusus oleh beberapa pelanggan adalah paparan langsung dari SAP Enterprise Portal ke Internet sementara host komputer virtual tersambung ke jaringan perusahaan melalui terowongan VPN situs-ke-situs atau ExpressRoute. Untuk skenario seperti itu, Anda harus memastikan bahwa port tertentu terbuka dan tidak diblokir oleh firewall atau kelompok keamanan jaringan.

Portal awal URI adalah http(s): <Portalserver> :5XX00/irj dimana port terbentuk seperti yang didokumentasikan oleh SAP di https://help.sap.com/saphelp_nw70ehp1/helpdata/de/a2/f9d7fed2adc340ab462ae159d19509/frameset.htm .

Konfigurasi titik akhir

Jika Anda ingin menyesuaikan URL dan/atau port SAP Enterprise Portal Anda, periksa dokumentasi ini:

Ketersediaan Tinggi (HA) dan Pemulihan Bencana (DR) untuk SAP NetWeaver yang berjalan di Azure Virtual Machines

Definisi terminologi

Istilah ketersediaan tinggi (HA) umumnya terkait dengan seperangkat teknologi yang meminimalkan gangguan TI dengan menyediakan kelangsungan bisnis layanan TI melalui komponen yang redundan, toleran terhadap kesalahan, atau terlindung dari kegagalan di dalam pusat data yang sama. Dalam kasus kami, ini terjadi dalam satu Wilayah Azure.

Pemulihan bencana (DR) juga menargetkan untuk meminimalkan gangguan layanan IT, dan pemulihannya tetapi di berbagai pusat data, yang biasanya terletak ratusan kilometer jauhnya. Dalam kasus kami biasanya ini terjadi antara Wilayah Azure yang berbeda dalam wilayah geopolitik yang sama atau sebagaimana Anda tetapkan sebagai pelanggan.

Gambaran Umum Ketersediaan Tinggi

Kami dapat memisahkan pembahasan tentang ketersediaan tinggi SAP di Azure menjadi dua bagian:

  • Ketersediaan tinggi Infrastruktur Azure, misalnya HA komputasi (VM), jaringan, penyimpanan, dll. dan manfaatnya untuk meningkatkan ketersediaan aplikasi SAP.
  • Ketersediaan tinggi aplikasi SAP, misalnya HA komponen perangkat lunak SAP:
    • Server aplikasi SAP
    • Instans SAP ASCS/SCS
    • Server DB

dan bagaimana cara mengombinasikannya dengan Infrastruktur Azure HA.

Ketersediaan Tinggi SAP di Azure memiliki beberapa perbedaan dibandingkan dengan Ketersediaan Tinggi SAP di lingkungan fisik atau virtual lokal. Makalah dari SAP berikut menjelaskan konfigurasi Ketersediaan Tinggi SAP standar di lingkungan virtual di Windows: https://scn.sap.com/docs/DOC-44415. Tidak ada konfigurasi SAP-HA yang terintegrasi sapinst untuk Linux seperti yang ada untuk Windows. Mengenai SAP HA lokal untuk Linux, temukan informasi lebih lanjut di sini: https://scn.sap.com/docs/DOC-8541.

Ketersediaan Tinggi Infrastruktur Azure

Saat ini ada SLA VM tunggal sebesar 99,9%. Untuk mendapatkan gambaran seperti apa ketersediaan VM tunggal, Anda dapat membuat produk dari berbagai SLA Azure yang tersedia: https://azure.microsoft.com/support/legal/sla/.

Dasar perhitungan adalah 30 hari per bulan, atau 43200 menit. Oleh karena itu, waktu henti 0,05% sesuai dengan 21,6 menit. Seperti biasa, ketersediaan layanan yang berbeda akan berlipat ganda dengan cara berikut:

(Layanan Ketersediaan #1/100) * (Layanan Ketersediaan #2/100) * (Layanan Ketersediaan #3/100)

Seperti:

(99.95/100) * (99.9/100) * (99.9/100) = 0.9975 atau ketersediaan keseluruhan 99,75%.

Ketersediaan Tinggi Virtual Machine (VM)

Ada dua jenis peristiwa platform Azure yang dapat memengaruhi ketersediaan mesin virtual Anda: pemeliharaan yang direncanakan dan pemeliharaan yang tidak direncanakan.

  • Peristiwa pemeliharaan yang direncanakan adalah pembaruan berkala yang dilakukan oleh Microsoft ke platform Azure yang mendasarinya untuk meningkatkan keandalan, performa, dan keamanan keseluruhan infrastruktur platform yang dijalankan oleh komputer virtual Anda.
  • Peristiwa pemeliharaan yang tidak direncanakan terjadi ketika perangkat keras atau infrastruktur fisik yang mendasari komputer virtual Anda rusak dalam beberapa hal. Ini mungkin termasuk kegagalan jaringan lokal, kegagalan disk lokal, atau kegagalan tingkat rak lainnya. Ketika kegagalan seperti itu terdeteksi, platform Azure akan secara otomatis memigrasikan komputer virtual Anda dari server fisik yang tidak sehat yang menghosting komputer virtual Anda ke server fisik yang sehat. Peristiwa seperti itu jarang terjadi, tetapi juga dapat menyebabkan mesin virtual Anda melakukan reboot.

Untuk lebih jelasnya, lihatKetersediaan komputer virtual Windows di Azure dan Ketersediaan komputer virtual Linux di Azure.

Redundansi Azure Storage

Data di Akun Microsoft Azure Storage Anda selalu direplikasi untuk memastikan bahwa ketahanan dan ketersediaan tinggi, memenuhi Azure Storage SLA bahkan dalam menghadapi kegagalan perangkat keras sementara.

Karena Azure Storage menyimpan tiga gambar data secara default, RAID5 atau RAID1 di beberapa disk Azure tidak diperlukan.

Untuk lebih jelasnya, lihat Redundansi Azure Storage.

Memanfaatkan Infrastruktur Azure VM Restart untuk Mencapai Ketersediaan Aplikasi SAP yang Lebih Tinggi

Jika Anda memutuskan untuk tidak menggunakan fungsionalitas seperti Windows Server Failover Clustering (WSFC) atau Pacemaker di Linux (saat ini hanya didukung untuk SLES 12 dan lebih tinggi), Azure VM Restart digunakan untuk melindungi Sistem SAP dari waktu henti yang direncanakan dan tidak direncanakan dari server fisik Azure infrastruktur dan platform Azure yang mendasari keseluruhan.

Catatan

Penting untuk disebutkan bahwa Azure VM Restart terutama melindungi VM dan BUKAN aplikasi. VM Restart tidak menawarkan ketersediaan tinggi untuk aplikasi SAP, tetapi menawarkan tingkat ketersediaan infrastruktur tertentu dan oleh karena itu secara tidak langsung ketersediaan sistem SAP yang lebih tinggi. Juga tidak ada SLA untuk waktu yang dibutuhkan untuk menghidupkan ulang VM setelah pemadaman host yang direncanakan atau tidak direncanakan. Oleh karena itu, metode ketersediaan tinggi ini tidak cocok untuk komponen penting dari sistem SAP seperti (A)SCS atau DBMS.

Elemen infrastruktur penting lainnya untuk ketersediaan tinggi adalah penyimpanan. Misalnya Azure Storage SLA memiliki ketersediaan 99.9%. Jika seseorang menyebarkan semua VM dengan disknya ke dalam satu Akun Azure Storage, potensi ketidaktersediaan Azure Storage akan menyebabkan tidak tersedianya semua VM yang ditempatkan di Akun Azure Storage tersebut, dan juga semua komponen SAP yang berjalan di dalam VM tersebut.

Alih-alih menempatkan semua VM ke dalam satu Akun Azure Storage, Anda juga dapat menggunakan akun penyimpanan khusus untuk setiap VM, dan dengan cara ini meningkatkan ketersediaan aplikasi VM dan SAP secara keseluruhan dengan menggunakan beberapa Akun Azure Storage independen.

Disk terkelola Azure secara otomatis ditempatkan di Domain Kesalahan dari mesin virtual yang dilampirkan. Jika Anda menempatkan dua komputer virtual dalam set ketersediaan dan menggunakan Disk Terkelola, platform akan menangani pendistribusian Disk Terkelola ke dalam Domain Kesalahan yang berbeda juga. Jika Anda berencana untuk menggunakan Penyimpanan Premium, kami juga sangat menyarankan untuk menggunakan Kelola Disk.

Arsitektur sampel sistem SAP NetWeaver yang menggunakan infrastruktur Azure HA dan akun penyimpanan bisa terlihat seperti ini:

Diagram yang memperlihatkan sistem SAP NetWeaver yang menggunakan infrastruktur Azure HA dan akun penyimpanan.

Sampel arsitektur sistem SAP NetWeaver yang menggunakan infrastruktur Azure HA dan Disk Terkelola dapat terlihat seperti ini:

Memanfaatkan infrastruktur Azure HA untuk mencapai ketersediaan aplikasi SAP yang lebih tinggi

Untuk komponen SAP penting, kami telah mencapai hal-hal berikut sejauh ini:

  • Ketersediaan Tinggi Server Aplikasi SAP (AS)

    Instans server aplikasi SAP adalah komponen yang berlebihan. Setiap instans SAP AS disebarkan pada VM sendiri, yang berjalan di Azure Fault dan Upgrade Domain yang berbeda (lihat bab Domain Kesalahan dan Domain Peningkatan). Ini dipastikan dengan menggunakan set ketersediaan Azure (lihat bab Set Ketersediaan Azure). Potensi ketidaktersediaan yang direncanakan atau tidak direncanakan dari Kesalahan Azure atau Domain Peningkatan akan menyebabkan tidak tersedianya sejumlah VM yang dibatasi dengan instans SAP AS mereka.

    Setiap instans SAP AS ditempatkan di akun Azure Storage-nya sendiri - potensi tidak tersedianya satu Akun Azure Storage akan menyebabkan tidak tersedianya hanya satu VM dengan instans SAP AS-nya. Namun, perlu diketahui bahwa ada batas Akun Azure Storage dalam satu langganan Azure. Untuk memastikan mulai otomatis instans (A)SCS setelah VM reboot, pastikan untuk mengatur parameter Autostart di profil mulai instans (A)SCS yang dijelaskan dalam bab Menggunakan Autostart untuk instans SAP. Baca juga bab Ketersediaan Tinggi untuk Server Aplikasi SAP untuk lebih jelasnya.

    Bahkan jika Anda menggunakan Disk Terkelola, disk tersebut juga disimpan di Akun Azure Storage dan bisa tidak tersedia jika terjadi gangguan penyimpanan.

  • Ketersediaan Lebih Tinggi instans SAP (A)SCS

    Di sini kami menggunakan Azure VM Restart untuk melindungi VM dengan instans SAP (A)SCS yang dipasang. Dalam kasus waktu henti yang direncanakan atau tidak direncanakan dari server Azure, VM akan dihidupkan ulang di server lain yang tersedia. Seperti disebutkan sebelumnya, Azure VM Restart terutama melindungi VM dan BUKAN aplikasi dalam kasus ini, instans (A)SCS. Melalui VM Restart, kami akan mencapai ketersediaan instans SAP (A)SCS yang lebih tinggi secara tidak langsung. Untuk memastikan mulai otomatis instans (A)SCS setelah VM reboot, pastikan untuk mengatur parameter Autostart di profil awal instans (A)SCS yang dijelaskan dalam bab Menggunakan Autostart untuk instans SAP. Ini berarti instans (A) SCS sebagai Single Point of Failure (SPOF) yang berjalan dalam satu VM akan menjadi faktor penentu ketersediaan seluruh lanskap SAP.

  • Ketersediaan Lebih Tinggi Server DBMS

    Di sini, mirip dengan kasus penggunaan instans SAP (A)SCS, kami menggunakan Azure VM Restart untuk melindungi VM dengan perangkat lunak DBMS yang dipasang, dan kami mencapai ketersediaan perangkat lunak DBMS yang lebih tinggi melalui VM Restart. DBMS yang berjalan dalam satu VM juga merupakan SPOF, dan merupakan faktor penentu untuk ketersediaan seluruh lanskap SAP.

Aplikasi SAP Ketersediaan Tinggi di Azure IaaS

Untuk mencapai ketersediaan tinggi sistem SAP penuh, kami perlu melindungi semua komponen sistem SAP penting, misalnya server aplikasi SAP yang berlebihan, dan komponen unik (misalnya Single Point of Failure) seperti instans SAP (A)SCS, dan DBMS.

Ketersediaan Tinggi untuk Server Aplikasi SAP

Untuk instans server/dialog aplikasi SAP, tidak perlu memikirkan solusi ketersediaan tinggi tertentu. Ketersediaan tinggi dicapai dengan redundansi dan dengan demikian terdapat cukup banyak di komputer virtual yang berbeda. Semuanya harus ditempatkan dalam set ketersediaan Azure yang sama untuk menghindari kemungkinan bahwa VM mungkin diperbarui pada saat yang sama selama waktu henti pemeliharaan yang direncanakan. Fungsionalitas dasar, yang dibangun di atas Domain Peningkatan dan Kesalahan yang berbeda dalam Unit Skala Azure telah diperkenalkan di bab Peningkatan Domains. Set ketersediaan Azure disajikan di bab Set Ketersediaan Azure dari dokumen ini.

Tidak ada jumlah Domain Kesalahan dan Peningkatan yang tidak terbatas yang dapat digunakan oleh ketersediaan Azure yang diatur dalam Unit Skala Azure. Ini berarti bahwa dengan menempatkan sejumlah VM ke dalam satu set ketersediaan, cepat atau lambat akan ada lebih dari satu VM yang berakhir di Domain Kesalahan atau Peningkatan yang sama.

Dengan menyebarkan beberapa contoh server aplikasi SAP di VM khusus mereka dan dengan asumsi bahwa kami mendapatkan lima Domain Peningkatan, gambar berikut akan muncul di bagian akhir. Jumlah maksimum aktual dari domain kesalahan dan pembaruan dalam set ketersediaan mungkin berubah di masa mendatang:

HA dari Server Aplikasi SAP di Azure

Ketersediaan Tinggi untuk Layanan Pusat SAP di Azure

Untuk arsitektur ketersediaan tinggi Central Services SAP di Azure, lihat artikel Arsitektur ketersediaan tinggi dan skenario untuk SAP NetWeaver sebagai informasi awal. Artikel ini menunjuk ke deskripsi yang lebih rinci untuk sistem operasi tertentu.

Ketersediaan Tinggi untuk instans database SAP

Pengaturan SAP DBMS HA yang khas didasarkan pada dua VM DBMS ketika fungsionalitas ketersediaan tinggi DBMS digunakan untuk mereplikasi data dari instans DBMS aktif ke VM kedua ke dalam instans DBMS pasif.

Fungsionalitas Ketersediaan Tinggi dan Pemulihan Bencana untuk DBMS secara umum serta DBMS tertentu dijelaskan dalam Panduan Penyebaran DBMS.

Ketersediaan Tinggi End-to-End untuk Sistem SAP Lengkap

Berikut adalah dua contoh arsitektur SAP NetWeaver HA lengkap di Azure - satu untuk Windows dan satu untuk Linux.

Hanya untuk disk tidak terkelola: Konsep seperti yang dijelaskan di bawah ini mungkin perlu dikompromikan sedikit ketika Anda menyebarkan banyak sistem SAP dan jumlah VM yang digunakan melebihi batas maksimum Akun Azure Storage per langganan. Dalam kasus seperti itu, VHD VM perlu digabungkan dalam satu Akun Azure Storage. Biasanya Anda dapat melakukannya dengan menggabungkan VHD lapisan aplikasi SAP VM dari sistem SAP yang berbeda. Kami juga menggabungkan VHD yang berbeda dari VM DBMS yang berbeda dari sistem SAP yang berbeda dalam satu Akun Azure Storage. Dengan demikian hal in mempertimbangkan batas IOPS Akun Azure Storage (https://azure.microsoft.com/documentation/articles/storage-scalability-targets)

Windows logo. HA pada Windows

Diagram yang menunjukkan Arsitektur HA Aplikasi SAP NetWeaver dengan SQL Server di Azure IaaS.

Konstruksi Azure berikut digunakan untuk sistem SAP NetWeaver, untuk meminimalkan dampak oleh masalah infrastruktur dan patching host:

  • Sistem lengkap disebarkan pada Azure (diperlukan - lapisan DBMS, (A)instans SCS, dan lapisan aplikasi lengkap yang perlu dijalankan di lokasi yang sama).
  • Sistem lengkap berjalan dalam satu langganan Azure (diperlukan).
  • Sistem lengkap dijalankan dalam Azure Virtual Network yang sama (diperlukan).
  • Pemisahan VM dari satu sistem SAP menjadi tiga set ketersediaan dimungkinkan bahkan dengan semua VM milik Microsoft Azure Virtual Network yang sama.
  • Setiap lapisan (misalnya DBMS, ASCS, Server Aplikasi) harus menggunakan set ketersediaan khusus.
  • Semua VM yang menjalankan instans DBMS dari satu sistem SAP berada dalam satu set ketersediaan. Kami berasumsi bahwa ada lebih dari satu instans DBMS yang menjalankan VM per sistem sejak fitur ketersediaan tinggi DBMS asli digunakan, seperti SQL Server AlwaysOn atau Oracle Data Guard.
  • Semua VM yang menjalankan instans DBMS menggunakan akun penyimpanan mereka sendiri. Data DBMS dan file log direplikasi dari satu akun penyimpanan ke akun penyimpanan lain menggunakan fungsi ketersediaan tinggi DBMS yang menyinkronkan data. Tidak tersedianya satu akun penyimpanan akan menyebabkan tidak tersedianya satu simpul kluster SQL Windows, tetapi tidak seluruh layanan SQL Server.
  • Semua VM yang menjalankan instans (A)SCS dari satu sistem SAP berada dalam satu set ketersediaan. Kluster Failover Windows Server (WSFC) dikonfigurasikan di dalam VM tersebut untuk melindungi instans (A)SCS.
  • Semua VM yang menjalankan instans (A)SCS menggunakan akun penyimpanan mereka sendiri. (A) File instans SCS dan folder global SAP direplikasi dari satu akun penyimpanan ke akun penyimpanan lain menggunakan replikasi SIOS DataKeeper. Tidak tersedianya satu akun penyimpanan akan menyebabkan tidak tersedianya satu (A)SCS Windows simpul kluster, tetapi tidak seluruh layanan (A)SCS.
  • SEMUA VM yang mewakili lapisan server aplikasi SAP berada dalam set ketersediaan ketiga.
  • SEMUA VM yang menjalankan server aplikasi SAP menggunakan akun penyimpanan mereka sendiri. Tidak tersedianya satu akun penyimpanan akan menyebabkan tidak tersedianya satu server aplikasi SAP, ketika server aplikasi SAP lainnya terus berjalan.

Gambar berikut ini mengilustrasikan lanskap yang sama menggunakan Disk Terkelola.

Diagram yang menunjukkan Arsitektur HA Aplikasi SAP NetWeaver dengan SQL Server di Azure IaaS

Logo Linux. HA di Linux

Arsitektur untuk SAP HA di Linux di Azure pada dasarnya sama dengan Windows seperti yang dijelaskan di atas. Lihat SAP Note 1928533 untuk daftar solusi ketersediaan tinggi yang didukung.

Menggunakan Autostart untuk instans SAP

SAP menawarkan fungsionalitas untuk memulai instans SAP segera setelah dimulainya OS dalam VM. Langkah-langkah yang tepat didokumentasikan dalam SAP Knowledge Base Artikel1909114. Namun, SAP tidak merekomendasikan untuk menggunakan pengaturan lagi karena tidak ada kontrol dalam urutan restart untuk instans, dengan asumsi lebih dari satu VM terpengaruh atau beberapa instans berjalan per VM. Dengan asumsi skenario Azure yang khas dari satu instans server aplikasi SAP dalam VM dan kasus VM tunggal akhirnya dihidupkan ulang, Autostart tidak bersifat penting dan dapat diaktifkan dengan menambahkan parameter ini:

Autostart = 1

Ke profil awal instans SAP ABAP dan/atau Java.

Catatan

Parameter Autostart juga dapat mengalami beberapa kerusakan. Secara lebih rinci, parameter memicu dimulainya instans SAP ABAP atau Java ketika layanan Windows / Linux terkait instans dimulai. Itu tentu saja terjadi ketika sistem operasi boot up. Namun, restart layanan SAP juga merupakan hal yang umum untuk fungsionalitas Manajemen Siklus Hidup Perangkat Lunak SAP seperti SUM atau pembaruan atau peningkatan lainnya. Fungsionalitas ini sama sekali tidak mengharapkan instans dihidupkan ulang secara otomatis. Oleh karena itu, parameter Autostart harus dinonaktifkan sebelum menjalankan tugas tersebut. Parameter Autostart juga tidak boleh digunakan untuk instans SAP yang dikelompokkan, seperti ASCS/SCS/CI.

Lihat informasi tambahan mengenai autostart untuk instans SAP di sini:

Sistem SAP 3 Tingkat yang lebih besar

Ketersediaan Tinggi konfigurasi SAP 3 Tingkat telah dibahas di bagian sebelumnya. Tetapi bagaimana dengan sistem dengan persyaratan server DBMS terlalu besar untuk diletakkan di Azure, tetapi lapisan aplikasi SAP-nya dapat disebarkan ke Azure?

Lokasi konfigurasi SAP 3 Tingkat

Ini tidak didukung untuk membagi tingkat aplikasi itu sendiri atau tingkat aplikasi dan DBMS antara lokal dan Azure. Sistem SAP sepenuhnya disebarkan di tempat lokal ATAU di Azure. Juga tidak didukung untuk memiliki beberapa server aplikasi yang berjalan di tempat lokal dan beberapa lainnya di Azure. Itu adalah titik awal pembahasan. Kami juga tidak mendukung untuk memiliki komponen DBMS dari sistem SAP dan lapisan server aplikasi SAP yang disebarkan di dua Wilayah Azure yang berbeda. Misalnya, DBMS di US Barat dan lapisan aplikasi SAP di US Tengah. Alasan untuk tidak mendukung konfigurasi tersebut adalah sensitivitas latensi arsitektur SAP NetWeaver.

Namun, selama tahun lalu mitra pusat data mengembangkan lokasi bersama ke Wilayah Azure. Lokasi bersama ini sering berada di dekat pusat data Azure fisik dalam Wilayah Azure. Jarak pendek dan koneksi aset di lokasi bersama melalui ExpressRoute ke Azure dapat menghasilkan latensi yang kurang dari 2 milidetik. Dalam kasus seperti itu, dimungkinkan untuk menemukan lapisan DBMS (termasuk penyimpanan SAN/NAS) di lokasi bersama dan lapisan aplikasi SAP di Azure. Instans Besar HANA.

Pencadangan Offline sistem SAP

Tergantung pada konfigurasi SAP yang dipilih (2-Tingkat atau 3-Tingkat) mungkin ada kebutuhan untuk mencadangkan. Konten VM itu sendiri ditambah untuk memiliki cadangan database. Pencadangan terkait DBMS diharapkan dilakukan dengan metode database. Deskripsi terperinci untuk database yang berbeda, dapat ditemukan di Panduan DBMS. Di sisi lain, data SAP dapat dicadangkan secara offline (termasuk konten database juga) seperti yang dijelaskan di bagian ini atau secara online seperti yang dijelaskan di bagian berikutnya.

Cadangan offline pada dasarnya akan perlu dimatikan VM melalui portal Azure dan salinan disk VM dasar ditambah semua disk yang terpasang ke VM. Ini akan mempertahankan gambar titik waktu VM dan disk yang terkait. Disarankan untuk menyalin cadangan ke Akun Azure Storage yang berbeda. Oleh karena itu prosedur yang dijelaskan dalam bab Menyalin disk antara Akun Azure Storage dari dokumen ini akan berlaku.

Pemulihan status tersebut akan terdiri dari menghapus VM dasar serta disk asli VM dasar dan disk yang dipasang, menyalin kembali disk yang disimpan ke Akun Azure Storage atau grup sumber daya asli untuk disk terkelola, lalu meyebarkan ulang sistem. Artikel ini memperlihatkan contoh cara membuat skrip proses ini di PowerShell: https://www.westerndevs.com/_/azure-snapshots/

Pastikan untuk memasang lisensi SAP baru sejak memulihkan cadangan VM seperti yang dijelaskan di atas membuat kunci perangkat keras baru.

Pencadangan online dari sistem SAP

Pencadangan DBMS dilakukan dengan metode khusus DBMS seperti yang dijelaskan dalam Panduan DBMS.

VM lain dalam sistem SAP dapat dicadangkan menggunakan fungsionalitas Azure Virtual Machine Backup. Azure Virtual Machine Backup adalah metode standar untuk mencadangkan VM lengkap di Azure. Azure Backup menyimpan cadangan di Azure dan memungkinkan pemulihan VM lagi.

Catatan

Pada Desember 2015 menggunakan VM Backup TIDAK menyimpan ID VM unik yang digunakan untuk lisensi SAP. Ini berarti bahwa pemulihan dari cadangan VM memerlukan instalasi kunci lisensi SAP baru karena VM yang dipulihkan dianggap sebagai VM baru dan bukan pengganti yang pertama yang disimpan.

Windows logo. Windows

Secara teoritis, VM yang menjalankan database dapat dicadangkan secara konsisten juga jika sistem DBMS mendukung Windows VSS (Layanan Menyalin Bayangan Volume https://msdn.microsoft.com/library/windows/desktop/bb968832(v=vs.85).aspx) seperti, misalnya, SQL Server. Namun, perlu diketahui bahwa berdasarkan cadangan Azure VM, pemulihan database dalam waktu tertentu tidak dimungkinkan. Oleh karena itu, rekomendasinya adalah melakukan pencadangan database dengan fungsionalitas DBMS bukan mengandalkan Azure VM Backup.

Untuk membiasakan diri dengan Backup Azure Virtual Machine, mulai di sini: Cadangkan Azure VM dari pengaturan VM.

Kemungkinan lain adalah menggunakan kombinasi antara Microsoft Data Protection Manager yang dipasang di Azure VM dan Azure Backup untuk mencadangkan/memulihkan database. Informasi lebih lanjut dapat ditemukan di sini:Persiapan untuk mencadangkan beban kerja ke Azure dengan DPM Pusat Sistem.

Logo Linux. Linux

Tidak ada yang setara dengan Windows VSS di Linux. Oleh karena itu, hanya pencadangan yang konsisten dengan file yang dimungkinkan tetapi bukan pencadangan yang konsisten dengan aplikasi. Pencadangan SAP DBMS harus dilakukan menggunakan fungsionalitas DBMS. Sistem file yang menyertakan data terkait SAP dapat disimpan, misalnya, menggunakan tar seperti yang dijelaskan di sini: https://help.sap.com/saphelp_nw70ehp2/helpdata/en/d3/c0da3ccbb04d35b186041ba6ac301f/content.htm

Azure sebagai situs DR untuk lanskap SAP produksi

Sejak Pertengahan 2014, ekstensi ke berbagai komponen di sekitar Hyper-V, System Center, dan Azure memungkinkan penggunaan Azure sebagai situs DR untuk VM yang berjalan di tempat berdasarkan Hyper-V.

Sebuah blog yang menjelaskan detail cara menyebarkan solusi ini didokumentasikan di sini: Melindungi Solusi SAP dengan Azure Site Recovery.

Ringkasan ketersediaan tinggi untuk sistem SAP

Poin penting dari Ketersediaan Tinggi untuk sistem SAP di Azure adalah:

  • Pada titik ini, titik kegagalan tunggal SAP tidak dapat diamankan dengan cara yang persis sama seperti yang dapat dilakukan dalam penyebaran lokal. Alasannya adalah bahwa kluster Disk Bersama belum dapat dibangun di Azure tanpa menggunakan perangkat lunak pihak ketiga.
  • Untuk lapisan DBMS, Anda perlu menggunakan fungsionalitas DBMS yang tidak bergantung pada teknologi kluster disk bersama. Detail didokumentasikan di Panduan DBMS.
  • Untuk meminimalkan dampak masalah dalam Domain Kesalahan di infrastruktur Azure atau pemeliharaan host, Anda harus menggunakan rangkaian ketersediaan Azure:
    • Disarankan untuk memiliki satu ketersediaan yang ditetapkan untuk lapisan aplikasi SAP.
    • Disarankan untuk memiliki ketersediaan terpisah yang ditetapkan untuk lapisan SAP DBMS.
    • TIDAK disarankan untuk menerapkan ketersediaan yang sama yang ditetapkan untuk VM dari sistem SAP yang berbeda.
    • Disarankan untuk menggunakan Disk Terkelola Premium.
  • Untuk tujuan Pencadangan lapisan SAP DBMS, periksa Panduan DBMS.
  • Mencadangkan instans Dialog SAP tidak mungkin dilakukan karena biasanya akan lebih cepat bila menyebarkan ulang instans dialog sederhana.
  • Mencadangkan VM, yang berisi direktori global sistem SAP dan termasuk semua profil dari berbagai instans, memang bisa dilakukan dan harus dilakukan dengan Windows Backup atau, misalnya, tar di Linux. Karena ada perbedaan antara Windows Server 2008 (R2) dan Windows Server 2012 (R2), yang membuatnya lebih mudah untuk melalukan pencadangan menggunakan rilis Windows Server yang lebih baru, kami sarankan menjalankan Windows Server 2012 (R2) sebagai sistem operasi tamu Windows.

Langkah berikutnya

Baca artikelnya:

Microsoft Azure memungkinkan perusahaan untuk memperoleh sumber daya komputasi dan penyimpanan dalam waktu minimal tanpa siklus pengadaan yang panjang. Layanan Azure Virtual Machine memungkinkan perusahaan untuk menyebarkan aplikasi klasik, seperti aplikasi berbasis SAP NetWeaver ke Azure dan memperluas keandalan dan ketersediaan mereka tanpa memiliki sumber daya lebih lanjut yang tersedia secara lokal. Layanan Azure Virtual Machine juga mendukung konektivitas lintas lokasi, yang memungkinkan perusahaan untuk secara aktif mengintegrasikan Azure Virtual Machine ke dalam domain lokal, Private Clouds, dan Lanskap Sistem SAP mereka. Laporan resmi ini menjelaskan dasar-dasar Microsoft Azure Virtual Machine dan memberikan panduan perencanaan dan pertimbangan implementasi untuk instalasi SAP NetWeaver di Azure dan karenanya harus menjadi dokumen untuk dibaca sebelum memulai penyebaran SAP NetWeaver aktual di Azure. Makalah ini melengkapi Dokumentasi Penginstalan SAP dan Catatan SAP, yang mewakili sumber daya utama untuk penginstalan dan penyebaran perangkat lunak SAP pada platform tertentu.

Catatan

Artikel ini menggunakan modul Azure Az PowerShell, yang merupakan modul PowerShell yang direkomendasikan untuk berinteraksi dengan Azure. Untuk mulai menggunakan modul Az PowerShell, lihat Menginstal Azure PowerShell. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Ringkasan

Komputasi Cloud adalah istilah yang banyak digunakan yang semakin penting dalam industri IT, dari perusahaan kecil hingga perusahaan besar dan multinasional.

Microsoft Azure adalah Platform Cloud Services dari Microsoft yang menawarkan berbagai kemungkinan baru. Sekarang pelanggan dapat dengan cepat menyediakan dan membatalkan penyediaan aplikasi sebagai layanan di cloud, sehingga mereka tidak terbatas pada batasan teknis atau anggaran. Daripada menginvestasikan waktu dan anggaran pada infrastruktur perangkat keras, perusahaan dapat fokus pada aplikasi, proses bisnis, dan manfaatnya bagi pelanggan dan pengguna.

Dengan Microsoft Azure Virtual Machine Services, Microsoft menawarkan platform Infrastruktur sebagai Layanan (IaaS) yang komprehensif. Aplikasi berbasis SAP NetWeaver didukung di Azure Virtual Machines (IaaS). Laporan resmi ini menjelaskan cara merencanakan dan mengimplementasikan aplikasi berbasis SAP NetWeaver dalam Microsoft Azure sebagai platform pilihan.

Makalah itu sendiri berfokus pada dua aspek utama:

  • Bagian pertama menjelaskan dua pola penyebaran yang didukung untuk aplikasi berbasis SAP NetWeaver di Azure. Ini juga menjelaskan penanganan umum Azure dengan mempertimbangkan penyebaran SAP.
  • Detail bagian kedua mengimplementasikan berbagai skenario yang dijelaskan di bagian pertama.

Untuk sumber daya tambahan, lihat bab Sumber Daya dalam dokumen ini.

Definisi di muka

Di seluruh dokumen, kami menggunakan istilah berikut:

  • IaaS: Infrastruktur sebagai Layanan
  • PaaS: Platform sebagai Layanan
  • SaaS: Perangkat lunak sebagai Layanan
  • Komponen SAP: aplikasi SAP individu seperti ECC, BW, Solution Manager, atau S/4HANA. Komponen SAP dapat didasarkan pada teknologi ABAP atau Java tradisional atau aplikasi berbasis non-NetWeaver seperti Business Objects.
  • Lingkungan SAP: satu atau lebih komponen SAP dikelompokkan secara logis untuk melakukan fungsi bisnis seperti pengembangan, QAS, Pelatihan, DR, atau Produksi.
  • Lanskap SAP: Istilah ini mengacu pada seluruh aset SAP dalam lanskap IT pelanggan. Lanskap SAP mencakup semua lingkungan produksi dan non-produksi.
  • Sistem SAP: Kombinasi lapisan DBMS dan lapisan aplikasi, misalnya, sistem pengembangan SAP ERP, sistem uji SAP Business Warehouse, sistem produksi SAP CRM, dll. Dalam penyebaran Azure, tidak didukung untuk membagi dua lapisan ini antara lokal dan Azure. Sistem SAP disebarkan lokal atau disebarkan di Azure. Namun, Anda dapat menyebarkan sistem lanskap SAP yang berbeda ke Azure atau lokal. Misalnya, Anda dapat menyebarkan sistem pengembangan dan pengujian SAP CRM di Azure tetapi sistem produksi SAP CRM secara lokal.
  • Lintas lokasi atau hibrid: Menjelaskan skenario tempat VM disebarkan ke langganan Azure yang memiliki konektivitas situs ke situs, multi situs, atau ExpressRoute antara pusat data lokal dan Azure. Dalam dokumentasi umum Azure, jenis penyebaran ini juga digambarkan sebagai skenario lintas lokasi atau hibrid. Koneksi ini ditujukan untuk memperluas domain lokal, Active Directory/OpenLDAP lokal, dan DNS lokal ke Azure. Lanskap lokal diperluas ke aset Azure dari langganan. Memiliki ekstensi ini, VM dapat menjadi bagian dari domain lokal. Pengguna domain di domain lokal dapat mengakses server dan menjalankan layanan pada VM tersebut ( seperti layanan DBMS). Komunikasi dan resolusi nama antara VM yang disebarkan secara lokal dan VM yang disebarkan oleh Azure dapat dilakukan. Ini adalah kasus yang paling umum dan hampir eksklusif dalam menyebarkan aset SAP ke Azure. Untuk informasi selengkapnya, lihat artikel inidanini.
  • Ekstensi Pemantauan Azure, Pemantauan yang Disempurnakan, dan Ekstensi Azure untuk SAP: Jelaskan satu dan item yang sama. Ini menjelaskan ekstensi VM yang perlu digunakan oleh Anda untuk memberikan beberapa data dasar tentang infrastruktur Azure ke Agen Host SAP. SAP dalam catatan SAP mungkin menyebutnya sebagai Ekstensi Pemantauan atau Pemantauan yang Ditingkatkan. Di Azure, kami menyebutnya sebagai Ekstensi Azure untuk SAP.

Catatan

Penyebaran sistem SAP lintas lokasi atau hibrid adalah tempat komputer Virtual Machines Azure yang menjalankan sistem SAP adalah anggota domain lokal dan didukung untuk sistem SAP produksi. Konfigurasi cross-premise atau hybrid didukung untuk menyebarkan bagian atau menyelesaikan lanskap SAP ke Azure. Bahkan menjalankan lanskap SAP lengkap di Azure mengharuskan VM tersebut menjadi bagian dari domain lokal dan ADS/OpenLDAP.

Sumber

Titik masuk untuk beban kerja SAP pada dokumentasi Azure ditemukan di Mulai dengan SAP di mesin virtual Azure. Dimulai dengan titik masuk ini Anda menemukan banyak artikel yang membahas topik:

  • SAP NetWeaver dan Business One di Azure
  • Panduan SAP DBMS untuk berbagai sistem DBMS di Azure
  • Ketersediaan tinggi dan pemulihan bencana untuk beban kerja SAP di Azure
  • Panduan khusus untuk menjalankan SAP Hana di Azure
  • Panduan khusus untuk Azure HANA Large Instances untuk SAP Hana DBMS

Penting

Sedapat mungkin tautan ke Panduan Penginstalan SAP yang merujuk atau dokumentasi SAP lainnya digunakan (Referensi InstGuide-01, lihat http://service.sap.com/instguides). Dalam hal prasyarat, proses penginstalan, atau detail fungsi SAP tertentu, dokumentasi dan panduan SAP harus selalu dibaca dengan hati-hati, karena dokumen Microsoft hanya mencakup tugas-tugas khusus untuk perangkat lunak SAP yang dipasang dan dioperasikan di Microsoft Azure Virtual Machine.

Catatan SAP berikut terkait dengan topik SAP di Azure:

Nomor Note Judul
1928533 Aplikasi SAP di Azure: Produk dan Ukuran yang Didukung
2015553 SAP di Microsoft Azure: Prasyarat Dukungan
1999351 Pemecahan masalah meningkatkan pemantauan Azure untuk SAP
2178632 Metrik Pemantauan Utama untuk SAP di Microsoft Azure
1409604 Virtualisasi pada Windows: Pemantauan yang Ditingkatkan
2191498 SAP di Linux dengan Azure: Pemantauan yang ditingkatkan
2243692 Linux di Microsoft Azure (IaaS) VM: Masalah lisensi SAP
1984787 SUSE LINUX Enterprise Server 12: Catatan penginstalan
2002167 Red Hat Enterprise Linux 7.x: Penginstalan dan peningkatan
2069760 Penginstalan dan Peningkatan SAP Oracle Linux 7.x
1597355 Rekomendasi swap-space untuk Linux

Baca juga SCN Wiki yang berisi semua SAP Notes untuk Linux.

Batasan default umum dan batasan maksimum langganan Azure dapat ditemukan di artikel ini.

Skenario yang Mungkin

SAP sering dipandang sebagai salah satu aplikasi paling penting dalam perusahaan. Arsitektur dan operasi aplikasi ini sebagian besar kompleks dan memastikan bahwa Anda memenuhi persyaratan tentang ketersediaan dan kinerja adalah penting.

Dengan demikian perusahaan harus memikirkan dengan cermat penyedia cloud mana yang harus dipilih untuk menjalankan proses bisnis penting tersebut. Azure adalah platform cloud publik yang ideal untuk aplikasi SAP penting bisnis dan proses bisnis. Mengingat berbagai infrastruktur Azure, hampir semua sistem SAP NetWeaver yang ada, dan S/4HANA dapat di-host di Azure saat ini. Azure menyediakan banyak VM dengan banyak Terabyte memori dan lebih dari 200 CPU. Selain itu Azure menawarkan Instans Besar HANA, yang memungkinkan penyebaran HANA skala besar hingga 24 TB dan penyebaran scale-out SAP Hana hingga 120 TB. Seseorang dapat menyatakan hari ini bahwa hampir semua skenario SAP lokal dapat dijalankan di Azure juga.

Untuk deskripsi kasar tentang skenario dan beberapa skenario yang tidak didukung, lihat beban kerja SAP dokumen pada skenario yang didukung mesin virtual Azure.

Periksa skenario ini dan beberapa kondisi yang dinamai tidak didukung dalam dokumentasi yang direferensikan sepanjang perencanaan dan pengembangan arsitektur Anda yang ingin Anda terapkan ke Azure.

Secara keseluruhan pola penyebaran yang paling umum adalah skenario lintas tempat seperti yang ditampilkan

VPN dengan Konektivitas Situs-Ke-Situs (lintas tempat)

Alasan bagi banyak pelanggan untuk menerapkan pola penyebaran lintas tempat adalah fakta bahwa pola tersebut paling transparan bagi semua aplikasi untuk memperluas lokal ke Azure menggunakan Azure ExpressRoute dan memperlakukan Azure sebagai pusat data virtual. Karena semakin banyak aset yang dipindahkan ke Azure, infrastruktur dan infrastruktur jaringan yang diterapkan Azure akan tumbuh dan aset lokal akan berkurang sesuai. Semuanya transparan bagi pengguna dan aplikasi.

Agar berhasil menyebarkan sistem SAP ke Azure IaaS atau IaaS secara umum, penting untuk memahami perbedaan signifikan antara penawaran agen outsourcing atau hoster tradisional dan penawaran IaaS. Sedangkan hoster atau outsourcer tradisional menyesuaikan infrastruktur (jenis jaringan, penyimpanan dan server) dengan beban kerja yang ingin di-host pelanggan, melainkan tanggung jawab pelanggan atau mitra untuk mengkarakterisasi beban kerja dan memilih komponen Azure yang benar dari VM, penyimpanan, dan jaringan untuk penyebaran IaaS.

Untuk mengumpulkan data untuk perencanaan penyebaran Anda ke Azure, penting untuk:

  • Mengevaluasi produk SAP apa yang didukung berjalan di Azure VMs
  • Mengevaluasi rilis Sistem Operasi tertentu yang didukung dengan Azure VM tertentu untuk produk SAP tersebut
  • Mengevaluasi rilis DBMS apa yang didukung untuk produk SAP Anda dengan Azure VM tertentu
  • Mengevaluasi apakah beberapa rilis OS/DBMS yang diperlukan mengharuskan Anda melakukan rilis SAP, upgrade Paket Dukungan, dan peningkatan kernel untuk masuk ke konfigurasi yang didukung
  • Evaluasi apakah Anda perlu pindah ke sistem operasi yang berbeda untuk diterapkan di Azure.

Detail tentang komponen SAP yang didukung di Azure, unit infrastruktur Azure yang didukung dan rilis sistem operasi terkait dan rilis DBMS dijelaskan dalam artikel Apa perangkat lunak SAP yang didukung untuk penyebaran Azure. Hasil yang diperoleh dari evaluasi rilis SAP yang valid, sistem operasi, dan rilis DBMS berdampak besar pada upaya memindahkan sistem SAP ke Azure. Hasil dari evaluasi ini akan menentukan apakah mungkin ada upaya persiapan yang signifikan dalam kasus peningkatan rilis SAP atau perubahan sistem operasi diperlukan.

Wilayah Azure

Layanan Azure Microsoft dikumpulkan di wilayah Azure. Wilayah Azure adalah salah satu atau kumpulan dari pusat data yang berisi perangkat keras dan infrastruktur yang menjalankan dan menghosting berbagai layanan Azure. Infrastruktur ini mencakup sejumlah besar simpul yang berfungsi sebagai simpul komputasi atau simpul penyimpanan, atau menjalankan fungsionalitas jaringan.

Untuk daftar wilayah Azure yang berbeda, periksa artikel Geografi Azure. Tidak semua wilayah Azure menawarkan layanan yang sama. Tergantung pada produk SAP yang ingin Anda jalankan, dan sistem operasi dan DBMS yang terkait dengannya, Anda dapat berakhir dalam situasi yang wilayah tertentu tidak menawarkan jenis VM yang Anda butuhkan. Ini terutama berlaku untuk menjalankan SAP Hana, di mana Anda biasanya membutuhkan VM dari seri VM M/Mv2. Keluarga VM ini hanya disebarkan di subset wilayah. Anda dapat mengetahui VM, jenis, jenis penyimpanan Azure, atau, Layanan Azure lainnya yang tersedia di wilayah mana dengan bantuan situs Produk tersedia menurut wilayah. Saat Anda memulai perencanaan dan memiliki wilayah tertentu sebagai wilayah utama dan akhirnya wilayah sekunder, Anda perlu menyelidiki terlebih dahulu apakah layanan yang diperlukan tersedia di wilayah tersebut.

Zona Ketersediaan

Beberapa wilayah Azure menerapkan konsep yang disebut Zona Ketersediaan. Zona Ketersediaan adalah lokasi yang dipisahkan secara fisik dalam wilayah Azure. Setiap Zona Ketersediaan terdiri dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan independen. Misalnya, menerapkan dua VM di dua Zona Ketersediaan Azure, dan menerapkan kerangka kerja ketersediaan tinggi untuk sistem SAP DBMS Anda atau Layanan Pusat SAP memberi Anda SLA terbaik di Azure. Untuk SLA mesin virtual khusus ini di Azure, periksa versi terbaru SLA Mesin Virtual. Sejak wilayah Azure berkembang dan diperluas dengan cepat selama beberapa tahun terakhir, topologi wilayah Azure, jumlah pusat data fisik, jarak di antara pusat data tersebut, dan jarak antara Zona Ketersediaan Azure bisa berbeda. Dan dengan latensi jaringan.

Prinsip Zona Ketersediaan tidak berlaku untuk layanan spesifik HANA dari Instans Besar HANA. Perjanjian Tingkat Layanan untuk Instans Besar HANA dapat ditemukan dalam artikel SLA untuk SAP Hana pada Instans Besar Azure

Domain kesalahan

Domain Kesalahan mewakili unit kegagalan fisik, terkait erat dengan infrastruktur fisik yang terdapat dalam pusat data, dan sementara bilah atau rak fisik dapat dianggap sebagai Domain Kesalahan, tidak ada pemetaan langsung satu-ke-satu di antara keduanya.

Saat Anda menyebarkan beberapa Virtual Machines sebagai bagian dari satu sistem SAP di Layanan Mesin Virtual Microsoft Azure, Anda dapat memengaruhi Pengontrol Azure Fabric untuk menyebarkan aplikasi Anda ke Domain Kesalahan yang berbeda, sehingga memenuhi persyaratan SLA ketersediaan yang lebih tinggi. Namun, distribusi Domain Kesalahan melalui Unit Skala Azure (kumpulan ratusan simpul Komputasi atau simpul penyimpanan dan jaringan) atau penugasan VM ke Domain Kesalahan tertentu adalah sesuatu yang tidak memiliki kontrol langsung. Untuk mengarahkan pengontrol Azure fabric untuk menyebarkan sekumpulan VM di atas Domain Kesalahan yang berbeda, Anda perlu menetapkan ketersediaan Azure yang diatur ke VM pada waktu penyebaran. Untuk informasi selengkapnya tentang kumpulan ketersediaan Azure, lihat bab Kumpulan ketersediaan Azure di dokumen ini.

Domain Peningkatan

Peningkatan Domain mewakili unit logis yang membantu menentukan bagaimana VM dalam sistem SAP, yang terdiri dari instans SAP yang berjalan di beberapa VM, diperbarui. Ketika pemutakhiran terjadi, Microsoft Azure melewati proses pembaruan Domain Pemutakhiran ini satu per satu. Dengan menyebarkan VM pada waktu penyebaran di atas Domain Peningkatan yang berbeda, Anda dapat melindungi sistem SAP Anda sebagian dari potensi waktu henti. Untuk memaksa Azure menerapkan VM dari sistem SAP yang tersebar di berbagai Domain Peningkatan, Anda perlu mengatur atribut tertentu pada waktu penyebaran setiap VM. Mirip dengan Domain Kesalahan, Unit Skala Azure dibagi menjadi beberapa Domain Pemutakhiran. Untuk mengarahkan pengontrol Azure fabric untuk menyebarkan sekumpulan VM di atas Domain Peningkatan yang berbeda, Anda perlu menetapkan Set Ketersediaan Azure ke VM pada waktu penyebaran. Untuk informasi selengkapnya tentang kumpulan ketersediaan Azure, lihat bab Kumpulan ketersediaan Azure di bawah.

Set ketersediaan Azure

Virtual Machines Azure dalam satu set ketersediaan Azure didistribusikan oleh Azure Fabric Controller melalui Domain Kesalahan dan Peningkatan yang berbeda. Tujuan distribusi atas Domain Kesalahan dan Peningkatan yang berbeda adalah untuk mencegah semua VM dari sistem SAP dimatikan jika terjadi pemeliharaan infrastruktur atau kegagalan dalam satu Domain Kesalahan. Secara default, VM bukan bagian dari kumpulan ketersediaan. Partisipasi VM dalam kumpulan ketersediaan ditentukan pada waktu penyebaran atau kemudian oleh konfigurasi ulang dan penyebaran ulang VM.

Untuk memahami konsep kumpulan ketersediaan Azure dan cara kumpulan ketersediaan terkait dengan Domain Kesalahan dan Peningkatan, baca artikel ini.

Saat Anda menentukan set ketersediaan dan mencoba mencampur berbagai VM dari keluarga VM yang berbeda dalam satu set ketersediaan, Anda mungkin mengalami masalah yang mencegah Anda memasukkan jenis VM tertentu ke dalam set ketersediaan tersebut. Alasannya adalah bahwa set ketersediaan terikat ke unit skala yang berisi jenis host komputasi tertentu. Dan jenis host komputasi tertentu hanya dapat menjalankan jenis keluarga VM tertentu. Misalnya, jika Anda membuat set ketersediaan dan menyebarkan VM pertama ke dalam set ketersediaan dan Anda memilih jenis VM dari keluarga Esv3 dan kemudian Anda mencoba untuk menyebarkan sebagai VM kedua VM dari keluarga M, Anda akan ditolak di alokasi kedua. Alasannya adalah bahwa VM keluarga Esv3 tidak berjalan pada perangkat keras host yang sama dengan mesin virtual keluarga M. Masalah yang sama dapat terjadi, ketika Anda mencoba mengubah ukuran VM dan mencoba memindahkan VM dari keluarga Esv3 ke jenis VM keluarga M. Dalam hal mengubah ukuran ke keluarga VM yang tidak dapat dihosting pada perangkat keras host yang sama, Anda perlu mematikan semua VM dalam set ketersediaan Anda dan mengubah ukurannya agar dapat berjalan pada jenis mesin host lainnya. Untuk SLA VM yang disebarkan dalam set ketersediaan, lihat artikel SLA Mesin Virtual.

Prinsip set ketersediaan dan pembaruan terkait serta domain kesalahan tidak berlaku untuk layanan spesifik HANA dari Instans Besar HANA. Perjanjian Tingkat Layanan untuk Instans Besar HANA dapat ditemukan dalam artikel SLA untuk SAP Hana pada Instans Besar Azure.

Penting

Konsep Zona Ketersediaan Azure dan kumpulan ketersediaan Azure saling eksklusif. Artinya, Anda dapat menyebarkan sepasang atau beberapa VM ke Zona Ketersediaan tertentu atau set ketersediaan Azure. Namun tidak keduanya.

Wilayah berpasangan Azure

Azure menawarkan pasangan Wilayah Azure tempat replikasi data tertentu diaktifkan di antara pasangan wilayah tetap ini. Pasangan wilayah didokumentasikan dalam artikel replikasi lintas wilayah di Azure: Kelangsungan bisnis dan pemulihan bencana. Seperti yang dijelaskan dalam artikel, replikasi data terkait jenis penyimpanan Azure yang dapat dikonfigurasi oleh Anda untuk direplikasi ke wilayah yang dipasangkan. Lihat juga artikel Redundansi penyimpanan di wilayah sekunder. Jenis penyimpanan yang memungkinkan replikasi seperti itu adalah jenis penyimpanan, yang tidak cocok untuk beban kerja DBMS. Dengan demikian kegunaan replikasi penyimpanan Azure akan terbatas pada penyimpanan blob Azure (seperti untuk tujuan cadangan) atau skenario penyimpanan latensi tinggi lainnya. Saat Anda memeriksa wilayah berpasangan dan layanan yang ingin Anda gunakan sebagai wilayah utama atau sekunder, Anda mungkin mengalami situasi yang layanan Azure dan/atau tipe VM yang ingin Anda gunakan di wilayah utama Anda tidak tersedia di wilayah yang dipasangkan. Atau Anda mungkin mengalami situasi wilayah yang berpasangan dengan Azure tidak dapat diterima karena alasan kepatuhan data. Untuk kasus tersebut, Anda perlu menggunakan wilayah yang tidak dipasangkan sebagai wilayah sekunder/pemulihan bencana. Dalam kasus seperti itu, Anda perlu berhati-hati pada replikasi beberapa bagian data yang akan direplikasi oleh Azure sendiri. Contoh tentang cara mereplikasi Direktori Aktif dan DNS Anda ke wilayah pemulihan bencana Anda dijelaskan dalam artikel Menyiapkan pemulihan bencana untuk Direktori Aktif dan DNS

Layanan mesin virtual Azure

Azure menawarkan berbagai macam mesin virtual yang dapat Anda pilih untuk digunakan. Tidak perlu membeli teknologi dan infrastruktur di muka. Layanan Azure VM menawarkan penyederhanaan pemeliharaan dan pengoperasian aplikasi dengan menyediakan komputasi dan penyimpanan sesuai permintaan untuk menghosting, menskalakan, dan mengelola aplikasi web dan aplikasi yang terhubung. Manajemen infrastruktur diotomatisasi dengan platform yang dirancang untuk ketersediaan tinggi dan penskalaan dinamis agar sesuai kebutuhan penggunaan dengan opsi beberapa model harga yang berbeda.

Menempatkan Layanan Mesin Virtual Microsoft Azure

Dengan mesin virtual Azure, Microsoft memungkinkan Anda untuk menyebarkan gambar server kustom ke Azure sebagai instans IaaS. Atau Anda dapat memilih dari banyak pilihan gambar sistem operasi yang dapat digunakan dari Azure Marketplace.

Dari perspektif operasional, Layanan Mesin Virtual Azure menawarkan pengalaman serupa sebagai mesin virtual yang digunakan di tempat. Anda bertanggung jawab atas administrasi, operasi, dan juga penambalan sistem operasi tertentu, yang berjalan di Azure VM dan aplikasinya di VM tersebut. Microsoft tidak lagi menyediakan layanan selain menghosting VM pada infrastruktur Azure-nya (Infrastructure as a Service - IaaS). Untuk beban kerja SAP yang Anda sebarkan sebagai pelanggan, Microsoft tidak memiliki penawaran di luar penawaran IaaS.

Platform Microsoft Azure adalah platform multi-penyewa. Akibatnya, sumber daya penyimpanan, jaringan, dan komputasi yang menghosting Azure VM, dengan beberapa pengecualian, dibagi antara penyewa. Pembatasan cerdas dan logika kuota digunakan untuk mencegah satu penyewa berdampak pada kinerja penyewa lain (tetangga yang berisik) dengan cara drastis. Khusus untuk mensertifikasi platform Azure untuk SAP Hana, Microsoft perlu membuktikan isolasi sumber daya untuk kasus yang beberapa VM dapat berjalan pada host yang sama secara teratur ke SAP. Meskipun logika di Azure mencoba untuk menjaga varians dalam bandwidth agar tetap kecil, platform yang sangat dibagikan cenderung memperkenalkan varians yang lebih besar dalam ketersediaan sumber daya/bandwidth daripada yang mungkin dialami pelanggan dalam penyebaran lokal mereka. Probabilitas bahwa sistem SAP di Azure dapat mengalami varians yang lebih besar daripada dalam sistem lokal perlu diperhitungkan.

Mesin virtual Azure untuk beban kerja SAP

Untuk beban kerja SAP, kami mempersempit pilihan ke berbagai keluarga VM yang cocok untuk beban kerja SAP dan beban kerja SAP Hana secara lebih khusus. Cara Anda menemukan jenis VM yang benar dan kemampuannya untuk bekerja melalui beban kerja SAP dijelaskan dalam dokumen Apa perangkat lunak SAP yang didukung untuk penyebaran Azure.

Catatan

Jenis VM yang disertifikasi untuk beban kerja SAP, tidak ada penyediaan sumber daya CPU dan memori yang berlebihan.

Di luar pilihan jenis VM yang didukung murni, Anda juga perlu memeriksa apakah jenis VM tersebut tersedia di wilayah tertentu berdasarkan situs Produk yang tersedia berdasarkan wilayah. Tetapi yang lebih penting, Anda perlu mengevaluasi apakah:

  • Sumber daya CPU dan memori dari berbagai jenis VM
  • Bandwidth IOPS dari berbagai jenis VM
  • Kemampuan jaringan dari berbagai jenis VM
  • Jumlah maksimum disk yang dapat dipasang
  • Kemampuan untuk memanfaatkan jenis penyimpanan Azure tertentu

sesuai dengan kebutuhan Anda. Sebagian besar data tersebut dapat ditemukan di sini (Linux) dan di sini (Windows) untuk jenis VM tertentu.

Sebagai model harga, Anda memiliki beberapa opsi penetapan harga berbeda yang mencantumkan seperti:

  • Prabayar
  • Satu tahun dicadangkan
  • Tiga tahun dicadangkan
  • Harga spot

Harga setiap penawaran yang berbeda dengan penawaran layanan yang berbeda di sekitar sistem operasi dan wilayah yang berbeda tersedia di situs Harga Mesin Virtual Linux dan Harga Windows Microsoft Azure Virtual Machines. Untuk detail dan fleksibilitas instans cadangan satu tahun dan tiga tahun, periksa artikel berikut:

Untuk informasi selengkapnya tentang harga spot, baca artikel Azure Spot Virtual Machines. Harga jenis VM yang sama juga dapat berbeda di antara wilayah Azure yang berbeda. Bagi beberapa pelanggan, ada baiknya untuk menyebarkan ke wilayah Azure yang lebih murah.

Selain itu, Azure menawarkan konsep host khusus. Konsep host khusus memberi Anda lebih banyak kontrol pada siklus patching yang dilakukan oleh Azure. Anda dapat mengatur waktu patching sesuai dengan jadwal Anda sendiri. Penawaran ini secara khusus menargetkan pelanggan dengan beban kerja yang mungkin tidak mengikuti siklus beban kerja normal. Untuk membaca konsep penawaran host khusus Azure, baca artikel Azure Dedicated Host. Menggunakan penawaran ini didukung untuk beban kerja SAP dan digunakan oleh beberapa pelanggan SAP yang ingin memiliki kontrol lebih pada patching infrastruktur dan rencana pemeliharaan Microsoft. Untuk informasi selengkapnya tentang cara Microsoft memelihara dan mempatching infrastruktur Azure yang menghosting mesin virtual, baca artikel Pemeliharaan untuk mesin virtual di Azure.

Mesin virtual Generasi 1 dan Generasi 2

Hypervisor Microsoft mampu menangani dua generasi mesin virtual yang berbeda. Format-format tersebut disebut Generasi 1 dan Generasi 2. Generasi 2 diperkenalkan pada tahun 2012 dengan hypervisor Windows Server 2012. Azure mulai menggunakan mesin virtual Generasi 1. Saat Anda menggunakan mesin virtual Azure, defaultnya masih menggunakan format Generasi 1. Sementara itu, Anda juga dapat menggunakan format VM Generasi 2. Artikel Dukungan untuk generasi 2 VM di Azure mencantumkan keluarga Azure VM yang dapat digunakan sebagai VM Generasi 2. Artikel ini juga mencantumkan perbedaan fungsional penting dari mesin virtual Generasi 2 karena dapat berjalan di cloud pribadi Hyper-V dan Azure. Yang lebih penting artikel ini juga mencantumkan perbedaan fungsional antara mesin virtual Generasi 1 dan VM Generasi 2, seperti yang dijalankan di Azure.

Catatan

Ada perbedaan fungsional dari VM Generasi 1 dan Generasi 2 yang berjalan di Azure. Baca artikel Dukungan untuk VM generasi 2 di Azure untuk melihat daftar perbedaan tersebut.

Memindahkan VM yang ada dari satu generasi ke generasi lain tidak mungkin terjadi. Untuk mengubah pembuatan mesin virtual, Anda perlu menyebarkan VM baru dari generasi yang Anda inginkan dan memasang ulang perangkat lunak yang Anda jalankan di mesin virtual generasi. Perubahan ini hanya mempengaruhi gambar VHD dasar VM dan tidak berdampak pada disk data atau saham NFS atau SMB yang terpasang. Disk data, saham NFS, atau SMB yang awalnya ditetapkan untuk, misalnya, pada VM Generasi 1.

Catatan

Menyebarkan VM keluarga Mv1 VM sebagai VM Generasi 2 dimungkinkan per awal Mei 2020. Dengan itu tampaknya kurang naik dan perampingan antara Mv1 dan Mv2 keluarga VM dimungkinkan.

Penyimpanan: Microsoft Azure Storage dan Disk Data

Microsoft Azure Virtual Machines menggunakan jenis penyimpanan yang berbeda. Saat menerapkan SAP pada Azure Virtual Machine Services, penting untuk memahami perbedaan antara dua jenis penyimpanan utama ini:

  • Penyimpanan non-Persisten dan mudah menguap.
  • Penyimpanan persisten.

Azure VM menawarkan disk nonpersisten setelah VM disebarkan. Jika kasus reboot VM, semua konten pada drive tersebut akan dihapus. Oleh karena itu, mengingat bahwa file data serta file log/pengulangan database dalam keadaan apa pun tidak boleh berada di drive nonpersisten. Mungkin terdapat pengecualian untuk beberapa database, di drive nonpersisten ini mungkin cocok untuk ruang tabel tempdb dan temp. Namun, hindari penggunaan drive tersebut untuk VM Seri- A karena drive nonpersisten dibatasi dalam throughput dengan rangkaian VM tersebut. Untuk detail lebih lanjut, baca artikel Memahami drive sementara di Windows VMs di Azure