Geçişle ilgili dikkat edilmesi gerekenler
Şirket içinde çalışan bir iş sistemi, aynı ortamda çalışan diğer hizmetlerle birleştirilmiş bir mimariye sahip olabilir. Geçirmek istediğiniz sistemle kuruluşunuzun şu anda kullandığı diğer uygulamalar ve hizmetler arasındaki ilişkileri anlamak önemlidir.
Teknoloji başlangıç şirketinizde tedarikçi veritabanı, bileşenlerin her zaman stokta olmasını ve üretim sürecinde kullanımları için tam zamanında ulaşmasını sağlamak için kullanılır. Stok denetleyicileri, sevkiyatlar geldikçe bu veritabanını güncelleştirmek için mobil cihazları kullanır ve alıcılar stok düzeylerini izlemek ve sipariş için en iyi zamanı belirlemek için bir web sitesi kullanır. Yöneticiler, süreci izlemek ve verimliliği artırmak için bir dizi iş açısından kritik rapor kullanır. Bu kullanıcıların hiçbirinin Azure'a geçişten olumsuz etkilenmediğinden emin olmak istiyorsunuz.
Burada buluta sorunsuz bir veritabanı geçişi planlamayı ve yürütmeyi öğreneceksiniz.
Bağımlılıkları araştırma
Karmaşık bir sistemde, bir bileşen nadiren tamamen bağımsız çalışır. Bunun yerine, diğer işlemlere ve bileşenlere çağrı yapar. Örneğin veritabanları, kullanıcı hesaplarını barındıran dizin hizmetlerine bağlı olabilir. Bir veritabanını buluta taşıdığınızda bu dizin hizmetine erişebilir misiniz? Aksi takdirde, kullanıcılar nasıl oturum açar? Bunun gibi bir bağımlılığı göz ardı ettiğinizde, veritabanında toplam hata olabilir.
Riskleri azaltmak için veritabanınızın aşağıdaki gibi hizmetlere bağımlı olup olmadığını denetleyin:
- Active Directory gibi dizin hizmetleri.
- Güvenlik sorumlularının diğer depoları.
- Diğer veritabanları.
- Web API'leri veya diğer ağ hizmetleri.
Ayrıca diğer bileşenlerin veritabanınıza bağlı olabileceğini unutmayın. Bağımlı bileşenleri yeniden yapılandırmadan veritabanını taşırsanız, bunun sonuçları ne olur? Örneğin, bir ürün kataloğu veritabanını taşırsanız ve genel kullanıma yönelik web sitesi, kullanıcılara hangi ürünleri sunacağını belirlemek için buna bağımlıysa, taşıma hizmette kesintiye neden olur mu?
Bu tür bileşenlerden herhangi birinin veritabanınıza bağlı olup olmadığını denetleyin:
- Web siteleri ve web API'leri.
- Mobil uygulamalar ve masaüstü yazılımları gibi istemci uygulamaları.
- Diğer veritabanları.
- Rapor.
- Veri ambarları.
Bu denetimleri yapmak için her veritabanı ve sistem bileşeniyle ilgili paydaşlar, yöneticiler ve geliştiricilerle görüşün. Daha sonra belgelere bakın, sistemlerin davranışını anladığınızdan emin değilseniz davranışları gözlemlemek için ağ yakalamaları gibi testler çalıştırmayı göz önünde bulundurun.
Geri çekilmeye hazırlanma
Herhangi bir geçiş projesinde her zaman bir hataya hazırlıklı olmanız gerekir. Buluta veritabanı geçiş projesinde en kötü sonuç, yeni veritabanının kullanılamaz duruma gelmesi ve kullanıcıların işlerini yapamamalarıdır. Şirket içi özgün ve değiştirilmemiş veritabanına geri dönmeyi planlayarak, şirketinizin karlılığı üzerinde büyük bir etkiye sahip olabilecek bu riski azaltmak yaygın bir durum olabilir.
Geri dönüş planı için şunları göz önünde bulundurun:
- Başarısız geçişten etkilenmeyen bir veritabanına geri dönebileceğinizden nasıl emin olabilirsiniz? Örneğin, geçişe başlamadan hemen önce tam veritabanı yedeği almanız kesinlikle önerilir.
- Geri dönmeniz gerekiyorsa veritabanının çevrimdışı olması ne kadar süreyle kabul edilebilir?
- Geri dönüş planı için ne kadar bütçeniz var? Örneğin, veritabanını ayrılmış bir geri dönüş sunucusuna çoğaltmayı göze alabilir misiniz? Öyleyse, geçişten hemen önce bu sunucuyu kapatabilirsiniz. Geri dönmek için bu sunucuyu önyüklersiniz. Yedekten geri yüklemek zorunda kalmadan geçişten hemen etkilenmeyen bir veritabanınız olur.
Çevrimdışı ve çevrimiçi geçiş
Veritabanını geçirmek için en az iki seçeneğiniz vardır:
Not
Çevrimiçi seçenek şu anda Veri Geçiş Hizmeti'ndeki MySQL veritabanları için kullanılamıyor.
- Sistemi durdurun, veritabanını aktarın, ardından yeni veritabanını kullanmak için sistemi yeniden yapılandırın ve yeniden başlatın. Bu bir çevrimdışı geçiştir.
- Veritabanını yeni konumuna taşırken sistemi çalışır durumda tutun, geçiş devam ederken özgün veritabanında gerçekleştirilen işlemleri yeni veritabanına iletin ve ardından uygulamalarınızı yeni veritabanına bağlanacak şekilde değiştirin. Bu çevrimiçi geçiştir.
Kullanıcıların geçiş sırasında verileri değiştirememelerini sağlamak için çevrimdışı geçiş yapmak daha kolaydır. Ancak veritabanınız meşgulse veya kuruluşunuzun başarısı için kritikse, bu mümkün olmayabilir.
Çevrimdışı geçişler
Veritabanınızın, normal iş saatlerinde tek bir saat diliminde çalışan analistlerden oluşan bir ekibi desteklediğini varsayalım. Ekip genellikle hafta sonları çalışmaz. Veritabanı genellikle Cuma günü 18:00 ile Pazar günü 09:00 arasında kullanılmaz.
Bu durumda, bu adımları izleyerek hafta sonu çevrimdışı geçiş yapabilirsiniz:
- Cuma akşamı tüm işlemler tamamlandıktan sonra veritabanını çevrimdışına alın.
- Veritabanının tam yedeğini alın veya dışarı aktarın.
- Şirket içi sunucuyu kapatın ve geri çekilmeniz gerekmesi ihtimaline karşı bu sunucuyu saklayın.
- Veritabanını hedef bulut sistemine geri yükleyin.
- Hedef sistemi çevrimiçine getirin.
- İstemcileri bulut veritabanına bağlanacak şekilde yeniden yapılandırın.
Bu durumda, hizmette bir kesintinin kullanıcılar üzerinde çok az etkisi olduğu uzun bir süre olduğundan çevrimdışı geçiş mümkündür. Bu süre boyunca, hiçbir değişikliği kaçırmayabileceğinizi bilerek veritabanını tam olarak yedekleyebilir ve geri yükleyebilirsiniz.
Çevrimiçi geçişler
Şimdi satış uygulamasını destekleyen başka bir veritabanını düşünün. Satış personeli dünyanın dört bir yanında dağıtılır ve hafta sonları da çalışır. Düşük etkinlik dönemi yoktur, veritabanı her zaman meşgul olur ve veritabanını önemli bir süre çevrimdışına alırsanız, bu kullanıcıları etkiler. Satış etkinliği iş açısından kritik olduğundan hizmette kesinti olması kuruluşun alt çizgisini doğrudan etkiler.
Böyle durumlarda çevrimiçi geçiş yapmayı göz önünde bulundurun. Çevrimiçi geçişte kapalı kalma süresi, yeni veritabanına geçiş için gereken süreyle sınırlıdır. Çevrimiçi geçiş yürütmek için Azure Veri Geçiş Hizmeti gibi bir araç kullanın. Çevrimiçi geçişlerin çevrimdışı geçişlerle arasındaki farklar şunlardır:
- Yedekleme veya dışarı aktarma işlemi yapmadan önce özgün veritabanını çevrimdışına taşımazsınız.
- Geçiş işlemi devam ederken değişiklikler eski veritabanına uygulanır.
- Geçiş aracı, geçiş öncesinde bu değişikliklerin yeni veritabanına kopyalanmasını sağlar. Bu genellikle değişiklikleri yeni veritabanına çoğaltmak için eski veritabanını yeniden yapılandırarak elde edilir.
Uygulama geçişi
Veritabanını geçirdikten sonra, yeni sisteme nasıl (ve ne zaman) geçiş yapmalı ve uygulamaları yeni veritabanını kullanacak şekilde güncelleştirmelisiniz? Aşağıdakiler olabilir:
- Uygulamaları tek tek yeni veritabanına taşıyın.
- Kullanıcıların alt kümelerini taşıma.
- Her iki yaklaşımın bir bileşimini benimseyin.
Amaç, uygulama geçişini, bir şey ters giderse kolayca geri alınabilecek küçük aşamalarda gerçekleştirmenizdir. Veritabanı geçişi için çevrimdışı veya çevrimiçi bir yaklaşım izlemiş olmanızdan bağımsız olarak, özgün kaynakta bulunan çalışan bir yapılandırmaya sahip olmanız gerekir. Teoride, hızlı bir şekilde orijinal kaynağa geri dönebileceksiniz. Ancak veriler sürekli değişiyorsa, bu değişikliklerin nerede yapıldığını göz önünde bulundurmanız gerekir.
- Çevrimdışı geçişte kaynak ve hedefler birbirinden bağımsızdır. Kullanıcılar ve uygulamalar artık verilerin tutarlı bir görünümünü göremeyebilir. İşlem sisteminde bu durum kabul edilemez olabilir. Bu durumda, her iki sistem de canlı kalırken veritabanları arasında çift yönlü çoğaltmanın bir biçimini korumanız gerekir. Alternatif olarak, bir uygulamanın amacı aylık veya haftalık raporlar oluşturmak, satış tahminleri oluşturmak veya başka istatistiksel işlemler gerçekleştirmekse, bu tutarlılık eksikliği o kadar da endişe verici olmayabilir. Bu tür uygulamalar, güncel verilere bağımlı olmak yerine verilerin "uzun bir görünümünü" alır. Bu ikinci durumda işlem uygulamaları yeni veritabanını kullanırken raporlama uygulamaları daha yavaş taşınır.
- Çevrimiçi geçişte, yeni veritabanı genellikle bir çoğaltma biçimiyle eski veritabanıyla eşitlenmiş olarak tutulur. Çoğaltma işlemi zaman uyumsuz olabileceğinden bir gecikme olabilir. Ancak, yeni veritabanındaki verilerde yapılan değişiklikler eskiye yayılmaz ve bu da olası çakışmalara neden olur. Eski veritabanında çalışan bir uygulama, yeni veritabanında değiştirilmiş olan verilerde çakışan bir değişiklik yapabilir. Çoğaltma, yeni veritabanındaki değişikliğin üzerine körü körüne yazıp "kayıp güncelleştirme" ile sonuçlanır.
Test yaklaşımları
Veritabanı işletmenizde kritik bir rol oynuyorsa, bir hatanın sonuçları kapsamlı olabilir. Bunun olmayacağına olan güveninizi artırmak için, geçirilen veritabanına karşı performans testleri çalıştırarak kullanıcıların üzerine yerleştirebileceği yükle başa çıkabileceğinden emin olun ve hızlı bir şekilde yanıt verin. Talep normalden çok daha yüksek olduğunda yoğun etkinlik dönemleri olabileceğini unutmayın. Geçirilen sisteminizin beklenen iş yükünü işlediğinden emin olmanız gerekir.
Kullanıcılara erişime izin vermeden önce her zaman yeni veritabanında bir tür regresyon testi gerçekleştirin. Bu testler sistemin davranışının ve işlevselliğinin doğru olduğunu doğrular.
Buna ek olarak, bir "bekletme testi" çalıştırmayı göz önünde bulundurmalısınız. Islatma testi, sistemin bir bütün olarak basınç altında nasıl çalıştığını görmek için tasarlanmış bir yük testidir. Islatma testi, yeni veritabanını strese sokar ve yüksek talep altında kararlı olup olmadığını belirler. Bekletme testi, yüksek talep devam ettiğinde ne olduğunu görmek için önemli bir süre boyunca çalışır.
Yeni sistemin kararlı olduğunu belirlediğinizde, kullanıcıları geçirmeye başlayabilirsiniz. Ancak, kullanıcıların yeni sistemi kabul edilebilir bulacağına ilişkin ek güvenceye ihtiyacınız olabilir. Bu noktada "kanarya testlerini" göz önünde bulundurabilirsiniz. Kanarya testi, kullanıcıların küçük bir alt kümesini şeffaf bir şekilde yeni sisteme yönlendirir, ancak bunlara eriştiğinin farkında değildir. Bu, yeni sistemle ilgili sorunları veya sorunları bulmanıza olanak sağlayan bir kör test biçimidir. Bu kullanıcıların yanıtlarını izleyin ve gerekli ayarlamaları yapın.
Paralel sistemlerin bakımı
Eski şirket içi veritabanını yeni bulut veritabanıyla paralel olarak çalıştırmayı seçmenizin çeşitli nedenleri vardır:
Test dönemleri. Önceki konuda gördüğünüz gibi, kişileri desteklemek için kullanmadan önce işlevselliğini, kararlılığını ve kapasitesini değerlendirmek için geçirilen veritabanında kanarya testleri çalıştırmak iyi bir fikirdir. Şirket içi sistemin paralel olarak korunması, yeni sistemle ilgili sorunlar varsa kullanıcıları eski sisteme döndürmek için hızlı bir yol sağlar.
Aşamalı geçişler. Beklenmeyen hataların üretim üzerindeki etkisini azaltmanın bir yolu, önce az sayıda kullanıcıyı yeni sisteme taşımak ve sonuçları izlemektir. Her şey sorunsuz çalışırsa, yeni veritabanında güven kazandıkça diğer kullanıcı gruplarını taşıyabilirsiniz. Kullanıcıları alfabetik olarak, departmana, konuma veya role göre, hepsi yeni veritabanında bulunana kadar taşıyabilirsiniz.
Parçalı geçişler. Bir diğer yaklaşım da geçişi kullanıcıya göre değil iş yüküne göre segmentlere ayırmaktır. Örneğin, insan kaynaklarını destekleyen veritabanı tablolarını satışları destekleyenlerden önce geçirebilirsiniz.
Tüm bu durumlarda, eski şirket içi veritabanının yeni bulut veritabanıyla paralel olarak çalıştığı bir dönem vardır. Eski veritabanında yapılan değişikliklerin yeni veritabanına da uygulandığından ve bunların ters yönde aktığından emin olmanız gerekir. Bu eşitlemeyi betik olarak yazabilir veya Azure Veri Geçiş Hizmeti gibi bir araç kullanabilirsiniz.
Paralel veritabanlarını korumaya ve değişiklikleri eşitlemeye karar verirseniz kendinize şu soruları sorun:
Çakışma çözümü. Şirket içi bir satırda yapılan bir değişikliğin, buluttaki aynı satırda yapılan farklı bir değişikliğe benzer bir zamanda gerçekleşmesi olası mı? Bu, hangi değişikliğin korunacağı belirsiz olan bir çakışmaya neden olur. Bu tür çakışmaları nasıl çözersiniz?
Ağ trafiği. Değişiklikler veritabanları arasında eşitlenirken ne kadar ağ trafiği oluşturulacak? Bu trafik için yeterli ağ kapasiteniz var mı?
Gecikme süresi. Veritabanlarından birinde değişiklik olduğunda, bu değişiklik diğer veritabanına ulaşmadan önce hangi gecikme (varsa) kabul edilebilir? Örneğin, bir ürün kataloğunda, yeni ürünlerin tüm kullanıcılar tarafından görülebilmesi için bir gün kadar beklemeniz gerekebilir. Ancak, veritabanında döviz kurları gibi kritik işlem bilgileri varsa, bu veriler anlık değilse çok daha sık eşitlenmelidir.
Parçalı geçiş
Parçalı geçiş, tam bir sistemi iş yüklerine böldüğünüz ve bir kerede bir iş yükünü geçirebileceğiniz yerdir.
Birden çok veritabanı
Karmaşık bir sistem, çeşitli iş yüklerini destekleyen birden çok veritabanı içerebilir. Örneğin, insan kaynakları StaffDB veritabanını kullanırken satış ekibinin hem ProductCatalogDB veritabanını hem de OrdersDB veritabanını sorgulayan mobil uygulamaları olabilir.
Elbette, veritabanı sisteminin tamamını tek seferde buluta geçirmeyi seçebilirsiniz. Veritabanlarını hem şirket içinde hem de bulutta çalıştırmanız gerekmeyen bu işlem daha basit olabilir. Geçiş sırasında bu veritabanlarının nasıl iletişim kuracaklarını düşünmeniz gerekmez. Ancak hata riskleri daha yüksektir. Tek bir sorun hem insan kaynakları ekibini hem de satış ekibini etkileyebilir.
Bir kerede bir iş yükünü taşıdığınız bir parçalı geçiş gerçekleştirerek orta ve büyük veritabanı sistemleri için bu riskleri azaltmayı göz önünde bulundurun. Bu örnekte, bir hatayla ilgili sorunlar insan kaynakları ekibiyle sınırlı olacağından ve sipariş almanıza engel olmadığından önce StaffDB veritabanını geçirmeyi düşünebilirsiniz. StaffDB geçişiyle ilgili sorunları çözerek diğer iş yükü geçişleri için geçerli olan dersleri öğreneceksiniz.
Daha sonra Ürün Kataloğu iş yükünü buluta geçirmeyi düşünebilirsiniz. Bunu yaparsanız, aşağıdakiler gibi soruları göz önünde bulundurun:
- Kataloğa yeni eklenen ürünlerin sipariş edilebilir olduğundan nasıl emin olursunuz?
- Şirket içinde kalan OrdersDB veritabanıyla herhangi bir veriyi eşitlemeniz gerekiyor mu?
- Yeni ürünlerin ürün kataloğundan OrdersDB veritabanına ulaşması için hangi gecikme süresi kabul edilebilir?
Tek veritabanı parçalı geçişleri
Tüm iş yüklerini destekleyen tek bir veritabanınız olsa bile, yine de bir parçalı geçişi göz önünde bulundurabilirsiniz. Örneğin, veritabanını aşağıdaki gibi parçalara ayırabilirsiniz:
- İk işlemlerini destekleyen tablolar.
- Satışları destekleyen tablolar.
- Analiz ve raporlamayı destekleyen tablolar.
İlk olarak İk operasyon tablolarını geçirirseniz, ortaya çıkan herhangi bir sorun yalnızca İk personelini etkiler. Satış ve veri analistleri eski veritabanında kesintisiz olarak çalışmaya devam eder.
Parçalı geçişi gerçekleştirmeden önce veritabanlarını ve uygulamalar tarafından nasıl kullanıldıklarını tam olarak anlamanız gerekir. Örneğin, veritabanınızdaki bazı tablolar hem satış hem de raporlamayı destekleyebileceğinden. Başka bir deyişle iş yüklerini temiz bir şekilde bölemezsiniz. Tüm iş yükleri geçirilene kadar bu tabloları şirket içi ve bulut veritabanları arasında eşitlemeniz gerekir.
Güvenlikle ilgili endişeler
Veritabanlarınız ürün ayrıntıları, kişisel personel bilgileri ve ödeme ayrıntıları gibi hassas veriler içerebilir; bu nedenle güvenlik her zaman yüksek önceliklidir. Geçiş sırasında ve yeni veritabanında bu verileri nasıl koruyacağınıza karar vermeniz gerekir.
Güvenlik duvarı koruması
İnternet'e bağlı bir uygulamada veritabanı sunucuları genellikle en az iki güvenlik duvarı tarafından korunur. örneğin, bu sunucular web sitelerini veya web API'lerini barındırıyorsa, ilk güvenlik duvarı interneti ön uç sunucularından ayırır. Dış güvenlik duvarında yalnızca TCP bağlantı noktası 80 açık olmalıdır, ancak engellenen adresler dışında tüm kaynak IP adresleri için bu bağlantı noktasının açık olması gerekir.
İkinci güvenlik duvarı, ön uç sunucuları veritabanı sunucularından ayırır. Veritabanı hizmetinin dış dünya tarafından bilinmeyen özel bir bağlantı noktası numarasında yayımlanması önerilir. İkinci güvenlik duvarında bu bağlantı noktası numarasını yalnızca ön uç sunucularının IP adresleri için açın. Bu düzenleme, kötü amaçlı bir İnternet kullanıcısından veritabanı sunucularına doğrudan iletişim olmasını engeller.
Veritabanı sunucularını Azure sanal makinelerine geçirmeyi planlıyorsanız, güvenlik duvarı kurallarını çoğaltmak için Ağ Güvenlik Grupları (NSG) içeren bir sanal ağ kullanın. MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı veya PostgreSQL için Azure Veritabanı kullanıyorsanız, Azure portal.
Kimlik doğrulaması ve yetkilendirme
Çoğu veritabanında, kimlerin hangi verilere erişip hangi verileri değiştirdiği üzerinde sıkı denetim sahibi olmanız gerekir. Bu denetim, kullanıcıların veritabanına bağlandıklarında olumlu bir şekilde tanımlanmasını gerektirir. Bu işleme kimlik doğrulaması adı verilir ve genellikle kullanıcı adı ve parola ile yapılır. MySQL, MariaDB ve PostgreSQL gibi veritabanı sistemleri kendi kimlik doğrulama mekanizmalarını sağlar. Sistemlerinizi buluta geçirirken kullanıcıların kimliğini güvenli bir şekilde doğrulamaya devam ettiğinizden emin olmanız gerekir.
Not
MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı ve PostgreSQL için Azure Veritabanı hizmetleri geleneksel MySQL, MariaDB ve PostgreSQL kimlik doğrulamasına öykünmektedir.
Kullanıcının kim olduğunu bildiğinizde, işinin parçası olan görevleri tamamlamak için bu kullanıcıya izinler atamanız gerekir. Bu işleme yetkilendirme adı verilir.
Veritabanı geçiş projesi için kullanıcıların bulut veritabanında doğru yetkilendirildiğinden emin olmanız gerekir:
Kullanıcı hesaplarının şirket içi sistemde nerede depolandığını öğrenin. MySQL'de kullanıcı hesapları genellikle veritabanının
user
mysqltablosunda depolanır, ancak örneğin Active Directory'de depolanan kullanıcı hesaplarıyla tümleştirmek mümkündür.
Tüm kullanıcı hesaplarının listesini alın. Örneğin, MySQL'de şu komutu kullanabilirsiniz:
SELECT host, user FROM mysql.user;
Her kullanıcı hesabı için veritabanına hangi erişime sahip olduklarını öğrenin. Örneğin, MySQL'de kullanıcı hesabı için
dbadmin@on-premises-hostşu komutu kullanabilirsiniz:
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
Bulut veritabanında her kullanıcı hesabını yeniden oluşturun. Örneğin, MySQL'de yeni bir hesap oluşturmak için şu komutu kullanabilirsiniz:
CREATE USER 'dbadmin'@'cloud-host'
Her kullanıcı hesabını bulut veritabanında doğru erişim düzeyine yetki verin. Örneğin, MySQL'de bir kullanıcının tam veritabanına erişmesine izin vermek için şu komutu kullanabilirsiniz:
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
Önemli
MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı veya PostgreSQL için Azure Veritabanı şu anda Azure Active Directory'da kullanıcı hesaplarını desteklemez. Şirket içinde kullanıcı hesaplarını depolamak için Active Directory kullanıyorsanız, bu kullanıcı hesaplarını buluttaki başka bir depoya geçirmeniz gerekir.
Şifreleme
Veriler ağ üzerinden gönderildiğinden, "ortadaki adam" saldırısı tarafından kesilebilir. Bunu önlemek için hem MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı hem de PostgreSQL için Azure Veritabanı iletişimleri şifrelemek için Güvenli Yuva Katmanı'nın (SSL) desteklenmesine neden olur. SSL varsayılan olarak zorunludur ve bu ayarı değiştirmemen kesinlikle önerilir.
SSL şifrelemesi kullanmak için istemci uygulamalarınızın bağlantı ayarlarını değiştirmeniz gerekebilir. Gerekli değişiklikleri (varsa) belirlemek için bu konuyu geliştiricilerinizle tartışın.
İzleme ve yönetim
Veritabanını geçirmeyi planlamanın bir parçası, veritabanı yöneticilerinin geçiş sonrasında görevlerini gerçekleştirmeye nasıl devam edeceğini göz önünde bulundurmaktır.
İzleme
Şirket içi veritabanı yöneticileri, donanım performans sorunları veya ağ erişimi çekişmesi gibi sorunları tespit etmek için düzenli olarak izlemek için kullanılır. Üretkenlik etkilenmeden önce sorunları çözebileceklerini güvence altına almak için izlerler. Düzenli olarak izlenmeyen tüm veritabanlarının er ya da geç sorunlara neden olmasını bekleyebilirsiniz.
Bulut veritabanları için de tam olarak aynı yaklaşımı benimsemeniz gerekir. Herhangi bir donanımı satın almadan, ayarlamadan ve yapılandırmadan kaynak ekleyebildiğiniz için Azure gibi bir PaaS sisteminde sorunları çözmek daha kolay olabilir. Ancak yine de geliştirme sorunlarını belirlemeniz gerektiğinden izleme, günlük görevleriniz arasında yüksek önceliklidir.
Veritabanlarını buluta geçirmeden önce, yöneticilerinizin şu anda hangi izleme araçlarını kullandığını öğrenin. Bu araçlar önerilen bulut tabanlı çözümünüzle uyumluysa, bunları yalnızca geçirilen veritabanlarına yeniden bağlamanız gerekebilir. Aksi takdirde alternatifleri araştırmanız gerekir.
Azure'ın bir dizi performans izleme aracı içerdiğini ve çok çeşitli performans sayaçları ile günlük verileri topladığını unutmayın. Azure İzleyici'yi yapılandırarak bu verileri Azure portal panoları ve grafikleri kullanarak görüntüleyebilirsiniz. Yöneticilerinizin ihtiyaçlarına özel olarak tasarlanmış özel grafikler, tablolar ve raporlar oluşturursunuz.
Yönetim
Veritabanı yöneticileriniz, şirket içi veritabanının şemasını ve içeriğini değiştirmek için tercih edilen araçları kullanır. Geçişten sonra aynı araçları kullanıyorlarsa uzmanlıklarından yararlanmaya devam edebilirsiniz. Mevcut araç kümesinin önerilen bulutta barındırılan veritabanıyla uyumlu olup olmadığını değerlendirerek başlayın. SQL gibi yaygın olarak benimsenen standartları temel alan birçok araç uyumlu olacaktır ancak uyumluluğun doğrulanması önemlidir. Geçiş sonrasında geçerli yönetim araçları çalışmazsa, yöneticilerinizle birlikte alternatifleri belirlemeyi deneyin.
Azure,MySQL, MariaDB ve PostgreSQL veritabanlarını yönetmek için kullanabileceğiniz çeşitli araçlar içerir:
Azure portalı. Bu web sitesi, veritabanlarını ve Azure bulutunda oluşturabileceğiniz diğer tüm kaynakları yapılandırmak, izlemek ve yönetmek için kullanabileceğiniz güçlü olanaklara sahiptir.
Azure PowerShell. Bu, çok sayıda komut içeren bir betik yürütme ortamı ve dilidir. Karmaşık veritabanı yönetim görevlerini otomatikleştirmek için Windows ve Linux ortamlarında kullanılabilen PowerShell'i kullanın.
Azure CLI. Bu, Azure'a bir komut satırı arabirimidir. Azure'daki hizmetleri ve kaynakları yönetmek için bu hizmeti kullanın. CLI'yı Windows ve Linux kabuk ortamlarından ve Bash betiklerinin içinden kullanabilirsiniz.