Apa yang Harus Ketahui Tentang Memindahkan SQL Server 2008/2008 R2 ke Azure

Memindahkan SQL Server 2008/2008 R2 Anda ke Azure – Semua Perusahaan Harus Tahu!

Tanggal: 30 Juli 2019

Lokasi: Webinar

Dukungan untuk SQL Server 2008 dan 2008 R2 berakhir pada 9 Juli. Apa artinya itu untuk beban kerja Perusahaan Anda? Haruskah Anda memanfaatkan pembaruan keamanan gratis Microsoft dengan pindah ke Azure atau Azure Stack? Apa saja pilihan Anda? Apa yang harus kamu lakukan Apakah masih ada waktu?

Bergabunglah dengan Manajer Program Senior Basis Data Microsoft SQL, Tokus Tambang, dan Penginjil Teknis SIOS dan MVP Manajemen Cloud dan Pusat Data, Dave Bermingham, karena mereka mencakup semua pertanyaan Anda yang tersisa mengenai EOS untuk SQL Server 2008 / R2; apa yang diharapkan untuk beban kerja SQL Server Anda setelah EOS, harapan untuk pindah ke Azure; Opsi Ketersediaan dan Pemulihan Bencana dan banyak lagi.

Selasa, 30 Juli 2019 1:00:00 PM EDT | 5:00:00 PM UTC

Daftar sekarang

Webinar disajikan oleh Dave Bermingham, Microsoft Cloud dan Datacenter Management MVP, dan Penginjil Teknis SIOS Technology Corp dan Mine Tokus, Insinyur Senior Premier Microsoft.

AWS Summit NYC

AWS Summit NYC

Tanggal: 11 Juli 2019

Lokasi: Kota New York, NY

AWS Global Summits adalah acara gratis yang menyatukan komunitas cloud computing untuk terhubung, berkolaborasi, dan belajar tentang AWS. Puncak diadakan di kota-kota besar di seluruh dunia, dan menarik teknologi dari semua industri dan tingkat keterampilan yang ingin menemukan bagaimana AWS dapat membantu mereka berinovasi dengan cepat dan memberikan solusi yang fleksibel dan andal dalam skala. Saat menghadiri KTT AWS, Anda akan mendengar dari Pemimpin AWS, Tenaga Ahli, Mitra, dan Pelanggan. Belajar dengan menghadiri sesi pelarian teknis, demonstrasi, lokakarya langsung, laboratorium, dan tantangan tim. Jaringan dengan Mitra AWS dan rekan-rekan Anda di Mitra dan Solusi Expo kami. SIOS adalah Sponsor Perunggu yang dipamerkan di stan 123 Pelajari lebih lanjut tentang AWS Global Summits

Video: Keuntungan SIOS Clustering

Video: Keuntungan SIOS Clustering

Setiap tahun, tugas Anda cenderung memberikan tingkat layanan yang lebih tinggi menggunakan infrastruktur yang ada dan anggaran TI yang lebih kecil. Toleransi untuk downtime atau kehilangan data hilang.  Aplikasi harus menyala 24/7 dan Anda harus dilindungi apakah itu pemadaman server, pemadaman jaringan, pemadaman aplikasi, atau bahkan hilangnya seluruh pusat data. Harapannya adalah bahwa jumlah downtime dan jumlah kehilangan data menyatu pada "0". Para profesional TI memiliki lebih banyak pilihan tentang bagaimana Anda akan mendukung pengguna akhir Anda apakah itu penyebaran server fisik, server virtual, atau bahkan teknologi cloud. Memilih solusi dilakukan untuk memahami tujuan bisnis, persyaratan teknis, dan batasan anggaran serta perlu memahami bagaimana Anda akan melindungi lingkungan untuk memastikannya selalu tersedia dan Anda tidak akan mengalami downtime atau kehilangan data. Ini biasanya dilakukan dengan menerapkan kluster berbasis SAN tradisional yang melibatkan dua atau lebih server yang terhubung ke beberapa jenis penyimpanan bersama. Jika ada masalah, aplikasi akan gagal dan membawa semuanya kembali online. Perangkat lunak SIOS mendukung hal ini dan membuatnya mudah diatur dan dikelola. Meskipun kluster berbasis SAN cocok untuk ketersediaan lokal yang tinggi, SAN umumnya mewakili biaya tinggi, kompleksitas, potensi kegagalan dalam arsitektur klaster Anda, dan juga tidak membantu Anda memecahkan masalah pemulihan bencana. Perangkat lunak SIOS memungkinkan Anda untuk membangun cluster Anda menggunakan perangkat keras pilihan Anda tetapi sekarang memanfaatkan penyimpanan lokal. SIOS menyediakan replikasi data tingkat blok waktu-nyata yang sepenuhnya sadar dan terintegrasi cluster memungkinkan Anda memanfaatkan penyimpanan lokal yang sangat cepat dengan konfigurasi cluster Anda. Juga, mengadopsi kluster SANLess dapat mengurangi biaya keseluruhan solusi dengan menghilangkan SAN. Akibatnya, Anda tidak hanya menghilangkan biaya perangkat keras SAN tetapi juga infrastruktur SAN dan biaya administrasi yang datang bersama dengan penghematan lisensi SAN Anda. Selain itu, Anda akan memotong satu titik kegagalan dalam arsitektur pengelompokan Anda sehingga tidak akan menghapus seluruh lingkungan. Anda juga dapat menghilangkan kehilangan data karena teknologi replikasi data tingkat blok waktu nyata kami membuat penyimpanan lokal tetap sinkron. Disediakan dengan perangkat lunak, ada juga antarmuka pengguna berbasis penyihir ramah pengguna. Singkatnya, SIOS memberi Anda fleksibilitas untuk melindungi aplikasi dan data penting misi Anda dalam lingkungan fisik, virtual, atau cloud.  Pelajari lebih lanjut tentang solusi ketersediaan tinggi kami.

Pelajari bagaimana perangkat lunak pengelompokan SIOS memudahkan melindungi aplikasi.

Mencapai Poin Pemulihan Konsisten Aplikasi SQL Server 2008 R2 Dengan Azure Site Recovery Di Azure

Mencapai Poin Pemulihan Konsisten Aplikasi SQL Server 2008 R2 Dengan Azure Site Recovery Di Azure

Jika Anda ingin menggunakan ASR untuk mereplikasi SQL Server 2008 R2 mandiri atau contoh berkerumun, Anda perlu memperbarui SQL Writer ke 2012 atau yang lebih baru. Anda dapat menggunakan versi SQL express karena ini adalah unduhan gratis. https://www.microsoft.com/en-us/download/details.aspx?id=29062 Setelah diunduh, navigasikan ke lokasi unduhan dan jalankan executable dengan / x.  Ini akan memberi Anda opsi untuk menentukan lokasi untuk mengekstrak file.

ENU  x64  SQLEXPRADV_x64_ENU.exe / x

Setelah ekstraksi selesai, navigasikan ke lokasi yang diekstraksi dan lokasi berikut: SQL 1033_enu_lp x64 setup x64 Di dalam folder itu Anda harus menemukan SQLWriter.msi.  Jalankan ini pada sistem di mana Anda ingin memperbarui penulis SQL. Anda sekarang akan dapat menggunakan ASR untuk melakukan titik pemulihan aplikasi yang konsisten dari SQL Server 2008 R2. Diproduksi ulang dengan izin dari Clusteringformeremortals.com

Dampak Pemadaman Awan Besar Mempengaruhi Mesin Hitung Google – Apakah Anda Siap? 

Dampak Pemadaman Awan Besar Mempengaruhi Mesin Hitung Google – Apakah Anda Siap?

Google pertama kali melaporkan "Masalah" pada 2 Juni 2019 pukul 12:25 PDT. Seperti sekarang umum dalam semua jenis bencana, laporan pemadaman ini pertama kali muncul di media sosial. Media sosial tampaknya merupakan tempat yang paling dapat diandalkan untuk mendapatkan semua jenis informasi di awal bencana sekarang.

Banyak layanan yang mengandalkan Google Compute Engine terkena dampaknya. Saya punya tiga anak remaja di rumah. Sesuatu naik ketika ketiga anak itu muncul dari gua-gua mereka, alias, kamar tidur, pada saat yang sama dengan ekspresi khawatir di wajah mereka. Snapchat, Youtube dan Discord semuanya offline! Mereka pasti berpikir bahwa ini adalah tanda pertama dari kiamat. Saya meyakinkan mereka bahwa ini bukanlah awal dari zaman kegelapan yang baru. Dan sebaliknya mereka harus pergi keluar dan melakukan pekerjaan halaman. Itu membuat mereka takut kembali ke dunia nyata dan mereka dengan cepat pergi mencari sesuatu yang lain untuk mengisi waktu mereka. Semua bercanda samping, ada banyak layanan yang dilaporkan turun, atau hanya tersedia di daerah-daerah tertentu. Debu masih menempel pada penyebab, luasnya dan cakupan pemadaman. Tetapi jelas bahwa pemadaman itu cukup signifikan dalam ukuran dan ruang lingkup, berdampak pada banyak pelanggan dan layanan termasuk Gmail dan layanan G-Suite lainnya, Vimeo dan banyak lagi.

Banyak layanan terkena dampak dari penghentian ini, Gmail, YouTube dan SnapChat hanya untuk beberapa nama. [/ caption]

Sementara kami menunggu analisis akar penyebab resmi pada pemadaman Google Compute Engine terbaru ini, Google melaporkan "tingkat kemacetan jaringan yang tinggi di AS bagian timur" yang menyebabkan downtime. Kami harus menunggu untuk melihat apa yang mereka tentukan menyebabkan masalah jaringan. Apakah itu kesalahan manusia, serangan cyber, kegagalan perangkat keras, atau sesuatu yang lain?

Apakah Anda Siap untuk Pemadaman Awan Ini?

Saya menulis selama pemadaman awan besar terakhir. Jika Anda menjalankan beban kerja kritis bisnis di cloud, terlepas dari penyedia layanan cloud, Anda berkewajiban untuk merencanakan pemadaman yang tak terhindarkan. Pemadaman multi-hari Azure pada 4 September 2018 terkait dengan kegagalan sistem HVAC sekunder untuk menendang selama lonjakan daya yang terkait dengan badai listrik. Sementara kegagalan itu hanya dalam satu pusat data, pemadaman listrik itu memaparkan beberapa layanan yang memiliki ketergantungan pada pusat data tunggal ini. Ini membuat pusat data itu sendiri titik kegagalan tunggal.

Memiliki Rencana Pemulihan Bencana yang Baik

Memanfaatkan infrastruktur cloud, meminimalkan risiko dengan terus menerus mereplikasi data penting antara Zona Ketersediaan, Wilayah, atau bahkan penyedia layanan cloud. Selain perlindungan data, memiliki prosedur untuk memulihkan aplikasi penting bisnis dengan cepat adalah bagian penting dari setiap rencana pemulihan bencana. Ada berbagai opsi replikasi dan pemulihan yang tersedia. Ini termasuk layanan yang disediakan oleh vendor cloud itu sendiri seperti Azure Site Recovery, untuk solusi spesifik aplikasi seperti SQL Server Always On Availability Groups, untuk solusi pihak ketiga seperti SIOS DataKeeper yang melindungi berbagai aplikasi yang berjalan pada Windows dan Linux. Memiliki strategi pemulihan bencana yang sepenuhnya tergantung pada penyedia cloud tunggal membuat Anda rentan terhadap skenario yang mungkin berdampak pada banyak wilayah dalam satu cloud. Bencana multi-pusat data atau multi-wilayah tidak mungkin terjadi. Namun, seperti yang kita lihat dengan pemadaman baru-baru ini dan pemadaman Azure musim gugur yang lalu, bahkan jika kegagalan bersifat lokal untuk pusat data tunggal, dampaknya dapat luas menjangkau beberapa pusat data atau bahkan wilayah dalam awan. Untuk meminimalkan risiko Anda, pertimbangkan skenario multi-cloud atau cloud hybrid di mana situs pemulihan bencana berada di luar platform cloud utama Anda. Cloud sama rentan terhadap pemadaman seperti pusat data Anda sendiri. Anda harus mengambil langkah-langkah untuk bersiap menghadapi bencana. Saya sarankan Anda mulai dengan melihat aplikasi paling penting bisnis Anda terlebih dahulu. Apa yang akan Anda lakukan jika mereka offline dan portal cloud untuk mengelolanya bahkan tidak tersedia? Bisakah kamu pulih? Apakah Anda memenuhi tujuan RTO dan RPO Anda? Jika tidak, mungkin sekarang saatnya untuk mengevaluasi kembali strategi Disaster Recovery Anda.

"Dengan gagal mempersiapkan, Anda bersiap untuk gagal." – Benjamin Franklin