Birçok kişi PostgreSQL DBMS'ye aşinadır ve küçük kurulumlarda kendini kanıtlamıştır. Ancak, büyük şirketler ve kurumsal gereksinimler söz konusu olduğunda bile Açık Kaynak eğilimi giderek daha belirgin hale geliyor. Bu yazımızda Postgres'i kurumsal bir ortama nasıl entegre edebileceğinizi anlatacağız ve örnek olarak Commvault yedekleme sistemini kullanarak bu veritabanı için bir yedekleme sistemi (BSS) oluşturma deneyimimizi paylaşacağız.
PostgreSQL değerini zaten kanıtladı; DBMS harika çalışıyor, Alibaba ve TripAdvisor gibi modaya uygun dijital işletmeler tarafından kullanılıyor ve lisans ücretlerinin olmaması onu MS SQL veya Oracle DB gibi canavarlara karşı cazip bir alternatif haline getiriyor. Ancak Kurumsal ortamda PostgreSQL'i düşünmeye başladığımız anda, hemen katı gereksinimlerle karşılaşırız: "Yapılandırma hata toleransı ne olacak? afet direnci? Kapsamlı izleme nerede? Otomatik yedeklemeler ne olacak? Teyp kitaplıklarını hem doğrudan hem de ikincil depolamada kullanmaya ne dersiniz?”
Bir yandan PostgreSQL, Oracle DB'deki RMAN veya SAP Database Backup gibi "yetişkinlere yönelik" DBMS'ler gibi yerleşik yedekleme araçlarına sahip değildir. Öte yandan, kurumsal yedekleme sistemleri tedarikçileri (Veeam, Veritas, Commvault) PostgreSQL'i destekleseler de aslında yalnızca belirli (genellikle bağımsız) bir konfigürasyonla ve çeşitli kısıtlamalarla çalışırlar.
Barman, Wal-g ve pg_probackup gibi PostgreSQL'e özgü yedekleme sistemleri, küçük PostgreSQL kurulumlarında veya diğer BT altyapı unsurlarının büyük ölçekli yedeklemelerinin gerekli olmadığı durumlarda son derece popülerdir. Örneğin, PostgreSQL'e ek olarak, altyapı fiziksel ve sanal bileşenleri de içerebilir. sunucularOpenShift, Oracle, MariaDB, Cassandra vb. gibi veritabanlarının tümünü ortak bir yedekleme aracı kullanarak yedeklemek en iyisidir. PostgreSQL için ayrı bir çözüm kullanmak kötü bir fikirdir: veriler bir yere diske kopyalanacak ve daha sonra banda taşınması gerekecektir. Bu yedekleme tekrarı, yedekleme süresini ve daha da önemlisi kurtarma süresini artırır.
Kurumsal bir çözümde, kurulumun yedeklenmesi, özel bir kümedeki belirli sayıda düğümle gerçekleşir. Aynı zamanda, örneğin Commvault yalnızca Birincil ve İkincil'in kesin olarak belirli düğümlere atandığı iki düğümlü bir kümeyle çalışabilir. Ve yalnızca Birincil'den yedekleme yapmak mantıklıdır çünkü İkincil'den yedeklemenin sınırlamaları vardır. DBMS'nin özellikleri nedeniyle İkincil'de bir döküm oluşturulmaz ve bu nedenle yalnızca dosya yedekleme olasılığı kalır.
Arıza süresi riskini azaltmak için, hataya dayanıklı bir sistem oluştururken "canlı" bir küme yapılandırması oluşturulur ve Birincil, farklı sunucular arasında kademeli olarak geçiş yapabilir. Örneğin, Patroni yazılımının kendisi, rastgele seçilen bir küme düğümünde Birincil'i başlatır. IBS'nin bunu kutudan çıkardıktan sonra takip etmesinin bir yolu yoktur ve konfigürasyon değişirse süreçler kesintiye uğrar. Yani, harici kontrolün getirilmesi ISR'nin etkili çalışmasını engeller çünkü kontrol sunucusu basitçe nereden ve hangi verilerin kopyalanması gerektiğini anlamaz.
Diğer bir sorun ise Postgres'te yedeklemenin uygulanmasıdır. Döküm yoluyla mümkündür ve küçük veritabanlarında çalışır. Ancak büyük veritabanlarında döküm uzun zaman alır, çok fazla kaynak gerektirir ve veritabanı örneğinin arızalanmasına yol açabilir.
Dosya yedekleme durumu düzeltir ancak büyük veritabanlarında tek iş parçacıklı modda çalıştığı için yavaştır. Ayrıca, satıcıların bir takım ek kısıtlamaları vardır. Dosya ve döküm yedeklemelerini aynı anda kullanamazsınız veya veri tekilleştirme desteklenmez. Pek çok sorun var ve çoğu zaman Postgres yerine pahalı ama kanıtlanmış bir DBMS'yi seçmek daha kolaydır.
Geri çekilecek hiçbir yer yok! Moskovalı geliştiriciler geride!
Ancak son zamanlarda ekibimiz zor bir zorlukla karşı karşıya kaldı: BT altyapısını oluşturduğumuz AIS OSAGO 2.0'ı oluşturma projesinde geliştiriciler yeni sistem için PostgreSQL'i seçti.
Büyük yazılım geliştiricilerin “modaya uygun” açık kaynaklı çözümleri kullanması çok daha kolaydır. Facebook'un bu DBMS'nin çalışmasını destekleyecek yeterli uzmanı var. Ve RSA örneğinde "ikinci günün" tüm görevleri omuzlarımıza düştü. Hata toleransını sağlamamız, bir küme oluşturmamız ve elbette yedeklemeyi ayarlamamız gerekiyordu. Eylemin mantığı şuydu:
- SRK'ya kümenin Birincil düğümünden yedekleme yapmayı öğretin. Bunu yapmak için SRK'nın onu bulması gerekir; bu da şu veya bu PostgreSQL küme yönetimi çözümüyle entegrasyonun gerekli olduğu anlamına gelir. RSA durumunda bunun için Patroni yazılımı kullanıldı.
- Veri hacmine ve kurtarma gereksinimlerine göre yedekleme türüne karar verin. Örneğin, sayfaları ayrıntılı bir şekilde geri yüklemeniz gerektiğinde bir döküm kullanın ve veritabanları büyükse ve ayrıntılı geri yükleme gerekmiyorsa dosya düzeyinde çalışın.
- Çok iş parçacıklı modda bir yedek kopya oluşturmak için çözüme blok yedekleme olanağını ekleyin.
Aynı zamanda, başlangıçta çok fazla ek bileşen olmadan etkili ve basit bir sistem yaratmaya başladık. Ne kadar az koltuk değneği olursa, personel üzerindeki iş yükü de o kadar az olur ve IBS başarısızlığı riski de o kadar düşük olur. Veeam ve RMAN kullanan yaklaşımları hemen hariç tuttuk çünkü iki çözümden oluşan bir set zaten sistemin güvenilmezliğine işaret ediyor.
Girişim için küçük bir sihir
Bu nedenle, yedekleme veri merkezine yansıtılan aynı altyapıyla, her biri 10 düğümden oluşan 3 küme için güvenilir yedeklemeyi garanti etmemiz gerekiyordu. PostgreSQL açısından veri merkezleri aktif-pasif prensibiyle çalışır. Toplam veritabanı boyutu 50 TB idi. Kurumsal düzeydeki herhangi bir kontrol sistemi bununla kolaylıkla başa çıkabilir. Ancak uyarı şu ki, Postgres başlangıçta yedekleme sistemleriyle tam ve derin uyumluluk konusunda bir ipucuna sahip değil. Bu nedenle başlangıçta PostgreSQL ile birlikte maksimum işlevselliğe sahip bir çözüm aramamız ve sistemi iyileştirmemiz gerekiyordu.
3 dahili “hackathon” düzenledik; elliden fazla gelişmeye baktık, onları test ettik, hipotezlerimizle bağlantılı değişiklikler yaptık ve tekrar test ettik. Mevcut seçenekleri inceledikten sonra Commvault'u seçtik. Kutudan çıktığı haliyle bu ürün, en basit PostgreSQL küme kurulumuyla çalışabiliyordu ve açık mimarisi, başarılı geliştirme ve entegrasyon konusunda (ki haklıydı) umutları artırıyordu. Commvault ayrıca PostgreSQL günlüklerini de yedekleyebilir. Örneğin Veritas NetBackup PostgreSQL açısından sadece tam yedekleme yapabilmektedir.
Mimarlık hakkında daha fazla bilgi. Commvault yönetim sunucuları iki veri merkezinin her birine CommServ HA konfigürasyonunda kuruldu. Sistem yansıtılmıştır, tek bir konsol aracılığıyla yönetilir ve HA açısından tüm kurumsal gereksinimleri karşılar.
Ayrıca her veri merkezinde, Fiber Kanal aracılığıyla SAN aracılığıyla yedeklemeler için özel olarak ayrılmış disk dizilerini ve bant kitaplıklarını bağladığımız iki fiziksel medya sunucusunu da başlattık. Genişletilmiş veri tekilleştirme veritabanları, medya sunucularının hata toleransını sağladı ve her sunucunun her CSV'ye bağlanması, herhangi bir bileşenin arızalanması durumunda sürekli çalışmayı mümkün kıldı. Sistem mimarisi, veri merkezlerinden biri çökse bile yedeklemenin devam etmesine olanak tanır.
Patroni her küme için bir Birincil düğüm tanımlar. Veri merkezindeki herhangi bir serbest düğüm olabilir, ancak yalnızca çoğunlukla. Yedeklemede tüm düğümler İkincildir.
Commvault'un hangi küme düğümünün birincil olduğunu anlamasını sağlamak için, sistemi (çözümün açık mimarisi sayesinde) Postgres ile entegre ettik. Bu amaçla, birincil düğümün mevcut konumunu yöneticiye bildiren bir komut dosyası oluşturduk. sunucu Commvault.
Genel olarak süreç şöyle görünür:
Patroni Birincil'i seçer → Keepalived IP kümesini alır ve betiği çalıştırır → seçilen küme düğümündeki Commvault aracısı bunun Birincil olduğuna dair bir bildirim alır → Commvault sahte istemci içindeki yedeklemeyi otomatik olarak yeniden yapılandırır.
Bu yaklaşımın avantajı, çözümün günlüklerin tutarlılığını, doğruluğunu veya Postgres örneğinin kurtarılmasını etkilememesidir. Ayrıca Commvault Birincil ve İkincil düğümlerini düzeltmeye artık gerek olmadığından kolayca ölçeklenebilir. Sistemin Birincil'in nerede olduğunu anlaması yeterlidir ve düğüm sayısı hemen hemen her değere artırılabilir.
Çözüm ideal gibi görünmüyor ve kendi nüansları var. Commvault tek tek veritabanlarını değil, yalnızca örneğin tamamını yedekleyebilir. Bu nedenle her veritabanı için ayrı bir örnek oluşturuldu. Gerçek istemciler sanal sözde istemciler halinde birleştirilir. Her Commvault sözde istemcisi bir UNIX kümesidir. Postgres için Commvault aracısının kurulu olduğu küme düğümleri buna eklenir. Sonuç olarak, sözde istemcinin tüm sanal düğümleri tek bir örnek olarak yedeklenir.
Her sözde istemcide kümenin aktif düğümü gösterilir. Commvault'a yönelik entegrasyon çözümümüz bunu tanımlıyor. Çalışma prensibi oldukça basittir: Bir düğümde bir küme IP'si yükseltilirse, komut dosyası Commvault aracı ikili dosyasındaki "aktif düğüm" parametresini ayarlar - aslında komut dosyası, belleğin gerekli kısmında "1" değerini ayarlar. . Aracı bu verileri CommServe'e iletir ve Commvault istenen düğümden yedekleme yapar. Ek olarak, yapılandırmanın doğruluğu komut dosyası düzeyinde kontrol edilerek yedekleme başlatılırken hataların önlenmesine yardımcı olur.
Aynı zamanda, büyük veritabanları birden çok iş parçacığında bloklar halinde yedeklenerek RPO ve yedekleme penceresi gereksinimlerini karşılar. Sistem üzerindeki yük önemsizdir: Tam kopyalar çok sık oluşmaz, diğer günlerde yalnızca günlükler toplanır ve yükün düşük olduğu dönemlerde.
Bu arada, PostgreSQL arşiv günlüklerini yedeklemek için ayrı politikalar uyguladık; bunlar farklı kurallara göre saklanır, farklı bir programa göre kopyalanır ve bu günlükler benzersiz veriler içerdiğinden tekilleştirme onlar için etkinleştirilmez.
Tüm BT altyapısında tutarlılığı sağlamak için küme düğümlerinin her birine ayrı Commvault dosya istemcileri kurulur. Postgres dosyalarını yedeklemelerin dışında tutarlar ve yalnızca işletim sistemi ve uygulama yedeklemeleri için tasarlanmıştır. Verilerin bu bölümünün de kendi politikası ve saklama süresi vardır.
Şu anda IBS üretkenlik hizmetlerini etkilemiyor ancak durum değişirse Commvault yük sınırlamayı etkinleştirebilir.
İyi mi? İyi!
Böylece, PostgreSQL küme kurulumu için yalnızca uygulanabilir değil, aynı zamanda tam otomatik bir yedekleme de aldık ve bu, kurumsal çağrılar için tüm gereksinimleri karşılıyor.
1 saatlik ve 2 saatlik RPO ve RTO parametreleri bir marjla kapatılmıştır; bu, depolanan veri hacminde önemli bir artış olsa bile sistemin bunlara uyacağı anlamına gelir. Pek çok şüphenin aksine PostgreSQL ve kurumsal ortamın oldukça uyumlu olduğu ortaya çıktı. Artık kendi deneyimimizden bu tür DBMS'lerin yedeklenmesinin çok çeşitli konfigürasyonlarda mümkün olduğunu biliyoruz.
Elbette bu yolda yedi çift demir çizmeyi yıpratmak, bir takım zorlukların üstesinden gelmek, birkaç tırmığa basmak ve bir takım hataları düzeltmek zorunda kaldık. Ancak artık bu yaklaşım zaten test edildi ve zorlu kurumsal koşullarda özel DBMS yerine Açık Kaynak uygulamak için kullanılabilir.
Kurumsal bir ortamda PostgreSQL ile çalışmayı denediniz mi?
Yazarlar:
Oleg Lavrenov, veri depolama sistemleri tasarım mühendisi, Jet Infosystems
Dmitry Erykin, Jet Infosystems bilgisayar sistemleri tasarım mühendisi
Kaynak: habr.com
