Odoo ve ERPNext İçin VPS Hosting Mimarisi: CPU, RAM, PostgreSQL ve Yedekleme

Odoo ve ERPNext İçin Doğru VPS Mimarisi Neden Bu Kadar Önemli?

Odoo veya ERPNext kurulumuna giren her ekip, proje planlama toplantısında benzer sorularla karşılaşıyor: “Kaç vCPU yeter? RAM ne kadar olmalı? PostgreSQL aynı VPS’te mi kalsın, ayrı sunucuya mı taşınsın? Yedekleri nereye, ne sıklıkla alacağız?” Bu sorulara net yanıt vermeden işe başlamak, ileride performans sorunları, veri kaybı riski ve gereksiz maliyetler olarak geri dönüyor. DCHost olarak onlarca Odoo ve ERPNext kurulumunda gördüğümüz ortak nokta şu: Başta doğru mimariyi kuran ekipler, sonradan çok daha az yangın söndürüyor ve altyapıyı büyütmek onlar için çok daha öngörülebilir oluyor.

Bu yazıda, Odoo ve ERPNext için VPS hosting mimarisini CPU ve RAM boyutlandırmasından PostgreSQL yapılandırmasına, yedekleme ve felaket kurtarma stratejisinden yüksek erişilebilirlik seçeneklerine kadar adım adım ele alacağız. Daha önce yayımladığımız Odoo ve ERPNext için VPS hosting rehberinde worker ve reverse proxy ayarlarına odaklanmıştık; bu yazı ise özellikle veritabanı mimarisi, kaynak planlama ve yedekleme tarafını derinleştiriyor. Amacımız, elinizde somut senaryolar ve net rakamlarla, ekibinizle aynı masada rahatça tartışabileceğiniz bir referans doküman bırakmak.

Odoo ve ERPNext İş Yükünü Anlamak: Asıl Kaynak Tüketen Ne?

Doğru mimariyi kurmanın ilk adımı, uygulamanın kaynağı nerede tükettiğini anlamaktan geçer. Odoo ve ERPNext tipik bir 3 katmanlı mimari gibi çalışır:

• Uygulama katmanı: Odoo/ERPNext servisleri, Python worker’lar, background job’lar.
• Veritabanı katmanı: PostgreSQL, tüm iş verilerinin tutulduğu kritik katman.
• Çevresel bileşenler: Nginx/Reverse proxy, e-posta queue, Redis/Celery benzeri kuyruk sistemleri (varsa).

Bu katmanların her biri farklı şekilde CPU, RAM, disk IO ve network tüketir. Örneğin:

• Stok, muhasebe, CRM gibi modüllere yoğun girilen işletmelerde veritabanı (PostgreSQL) disk IO ve RAM’i zorlar.
• Yoğun raporlama, pivot tablolar ve toplu ihracat işlemlerinde hem CPU hem de RAM tüketimi artar.
• Çok sayıda eşzamanlı kullanıcıya hizmet veren SaaS kurulumlarında uygulama worker sayısı arttıkça CPU baskısı belirginleşir.

Dolayısıyla mimariyi konuşurken “tek VPS yeter mi?” sorusundan önce şu sorulara yanıt vermek gerekir:

• Kaç aktif kullanıcı olacak, aynı anda sistemde kaçı çalışacak?
• Hangi modüller yoğun kullanılacak (muhasebe, üretim, envanter, e-ticaret vb.)?
• Gün içi yük dağılımı nasıl (sabah/akşam yoğun saatler, ay sonu/çeyrek sonu pikleri)?
• RPO/RTO hedefleriniz nedir (en fazla ne kadar veri kaybına ve kesintiye toleransınız var)?

CPU ve RAM Boyutlandırma: Farklı Ölçekler İçin Örnek Senaryolar

Her iş yükü farklıdır; ancak sahada gördüğümüz kurulumlara göre bazı başlangıç şablonları çıkarmak mümkün. Buradaki değerler, DCHost üzerinde çalışan gerçek Odoo/ERPNext kurulumlarından elde ettiğimiz ortalama ve güvenli başlangıç noktalarıdır. İhtiyaca göre yukarı/asağı ayarlamak her zaman mümkündür.

Küçük Ekipler (5–20 Kullanıcı): Tek VPS, Hepsi Bir Arada Mimari

Küçük ekipler için çoğu zaman tek bir güçlü VPS üzerinde hem uygulama hem PostgreSQL veritabanı tutmak pratik ve maliyet etkin bir çözümdür.

• Önerilen başlangıç: 2–4 vCPU, 8–12 GB RAM, NVMe SSD disk.
• Kullanım profili: Günlük operasyon (teklif, fatura, basit stok), hafif raporlama.
• Mimari:
  • Tek VPS üzerinde Odoo/ERPNext uygulaması + PostgreSQL.
  • Nginx reverse proxy ve isteğe bağlı Redis aynı makinede.
  • Harici bir yedek hedefi (Object Storage veya ayrı yedek VPS).

Bu senaryoda dikkat edilmesi gereken ana nokta, CPU’nun “burst” anlarında (örneğin ağır bir rapor çalışırken) PostgreSQL ve uygulamanın birbirini boğmaması. CPU ve RAM’i çok kısıtlı tutarsanız, veritabanı sorguları uzar, uygulama worker’ları sıraya girer, kullanıcı tarafında ekran geçişleri yavaşlar.

Orta Ölçekli Kurulumlar (20–80 Kullanıcı): Uygulama ve Veritabanını Ayırmak

20’nin üzerinde aktif kullanıcı ve sürekli çalışan arka plan işlerinin olduğu kurulumlarda, uygulama ile PostgreSQL’i ayrı VPS’lere bölmek ciddi avantaj sağlar.

• Önerilen başlangıç:
  • Uygulama VPS: 4–6 vCPU, 8–12 GB RAM.
  • PostgreSQL VPS: 4 vCPU, 16 GB RAM, yüksek IOPS’lı NVMe disk.
• Mimari avantajları:
  • Uygulama tarafında worker sayısını CPU’ya göre esnek arttırabilirsiniz.
  • Veritabanı için RAM’i ve disk performansını ayrı optimize edebilirsiniz.
  • Gelecekte sadece veritabanını daha güçlü bir VPS’e veya dedicated sunucuya taşıyarak ölçekleyebilirsiniz.

Bu modelde network gecikmesi kritik hale gelir. DCHost altyapısında aynı veri merkezindeki VPS’ler arasında gecikme çok düşük olduğundan, uygulama–DB ayrımı pratikte belirgin bir performans kaybı yaratmadan çalışır. Önemli olan, PostgreSQL’in disk performansı ve RAM’ini cömert tutmaktır.

Büyük Kurulumlar ve SaaS Senaryoları: Yatay Ölçekleme ve Çoklu VPS

Onlarca/ yüzlerce eşzamanlı kullanıcı, çok kiracılı (multi-tenant) SaaS projeleri veya ağır raporlama yapan kurulumlarda daha esnek bir mimari gerekir:

• Uygulama katmanı: Birden fazla VPS üzerinde Odoo/ERPNext instance’ları, araya konan Nginx/HAProxy ile yük dengeleme.
• Veritabanı katmanı: Güçlü bir PostgreSQL sunucusu (yüksek RAM + NVMe) ve en az bir read-replica.
• Destek servisler: Ayrı Redis/kuyruk sunucusu, ayrı loglama/izleme sunucusu.

Böyle bir mimari genellikle tek bir VPS’in sınırlarını aştığında, dedicated sunucu veya colocation seçeneklerine geçişle birlikte planlanır. DCHost tarafında, veritabanını güçlü bir dedicated sunucuya alıp uygulama katmanını esnek VPS’lerle çoğaltan hibrit yapılar sık kullandığımız bir yaklaşım.

PostgreSQL Mimarisi: Aynı VPS’te mi, Ayrı Sunucuda mı?

Odoo ve ERPNext’in kalbi PostgreSQL’dir. Yavaşlayan sorgular, şişen tablolar veya yanlış yapılandırılmış autovacuum, uygulama ne kadar iyi ölçeklenmiş olursa olsun tüm sistemi yavaşlatabilir. Bu yüzden “PostgreSQL’i nereye koyacağız?” sorusu mimarinin en kritik adımlarından biridir.

PostgreSQL’in Aynı VPS’te Tutulabileceği Senaryolar

Aşağıdaki durumlarda PostgreSQL’i uygulama ile aynı VPS üzerinde tutmak makul ve pratik bir çözümdür:

• Küçük–orta ölçek (20’den az eşzamanlı kullanıcı).
• Yoğun, karmaşık raporların nadir çalıştırıldığı senaryolar.
• Toplam veritabanı boyutunun nispeten küçük olduğu (örneğin < 50–80 GB) kurulumlar.
• Ağ gecikmesini tamamen ortadan kaldırmak istediğiniz basit mimariler.

Bu modelde dikkat edilmesi gerekenler:

• PostgreSQL için RAM’den makul bir pay (örneğin total RAM’in %30–40’ı) ayrılmalı.
• Disk mutlaka NVMe SSD olmalı; HDD veya yavaş SATA SSD performans sorunları yaratır.
• Odoo/ERPNext worker sayısı artırılırken PostgreSQL’in aynı CPU’yu paylaştığı unutulmamalı.

Ne Zaman Ayrı PostgreSQL VPS/Dedicated Sunucu Mantıklı?

Aşağıdaki sinyallerden bir veya birkaçı görünüyorsa veritabanını ayrı bir VPS veya dedicated sunucuya taşıma zamanı gelmiş demektir:

• PostgreSQL CPU kullanımı sürekli yüksek (%60–80+) ve raporlarda yavaşlamalar var.
• top/htop çıktısında IO wait değerleri anlamlı şekilde yükseliyor.
• Veritabanı boyutu onlarca/ yüzlerce GB seviyesine çıkmış durumda.
• Gelecekte replikasyon, read-replica veya analitik amaçlı ayrı bir veritabanı kopyası planlıyorsunuz.

Bu durumda tipik bir ayrım şöyle olur:

• PostgreSQL için: Daha az vCPU ama bol RAM (örneğin 4 vCPU, 32 GB RAM) ve yüksek IOPS’lı disk.
• Uygulama için: Daha fazla vCPU (örneğin 6–8 vCPU, 8–16 GB RAM), gerektiğinde yatay olarak çoğaltılabilir.

Veritabanını ayırdığınızda, yedekleme, replikasyon ve izleme için de daha temiz bir mimari elde edersiniz. Örneğin sadece PostgreSQL VPS’ine odaklanan bir PostgreSQL tuning seti uygulamak çok daha kolay hale gelir.

Temel PostgreSQL Ayarları: Odoo ve ERPNext İçin Başlangıç Noktaları

Her kurulum için ideal değerler farklı olsa da, sahada iyi çalışan bazı genel önerilerden bahsedebiliriz. Detaylı teknik anlatımı ilgili PostgreSQL makalemizde bulabilirsiniz, burada Odoo/ERPNext odağında özetleyeceğim.

• shared_buffers: Toplam RAM’in kabaca %20–25’i iyi bir başlangıçtır. Örneğin 16 GB RAM’li bir DB sunucusunda 4 GB shared_buffers makul bir değerdir.
• work_mem: Her sorgu için kullanılabilen bellek. Çok yüksek ayarlamak, çok sayıda eşzamanlı sorguda RAM’in tükenmesine neden olabilir. 16–64 MB aralığı güvenli bir başlangıçtır; ağır raporların çok olduğu kurulumlarda kademeli arttırılabilir.
• effective_cache_size: OS disk cache’ini de hesaba katan bir değer. Genelde toplam RAM’in %50–60’ı civarında ayarlamak, sorgu planlayıcısına daha doğru sinyaller verir.
• wal_level, checkpoint, autovacuum: Odoo/ERPNext gibi sürekli yazma yapan sistemlerde WAL ve autovacuum ayarlarının doğru yapılması kritik önemdedir; aksi halde tablolar şişer, performans bozulur.

Orta–büyük kurulumlarda, bağlantı havuzu (PgBouncer vb.) ile bağlantı sayısını kontrol etmek ve her Odoo worker’ın veritabanına ayrı ayrı yüklenmesini engellemek de oldukça etkilidir.

Bağlantı Havuzu, Replikasyon ve Yüksek Erişilebilirlik

Odoo ve ERPNext için sadece tek bir PostgreSQL sunucusu kullanmak, küçük kurulumlarda yeterli olabilir; ancak büyüyen iş yüklerinde bağlantı havuzu, replikasyon ve yüksek erişilebilirlik devreye girer.

PgBouncer ile Bağlantı Havuzu

Her Odoo/ERPNext worker’ı, PostgreSQL’e bir veya daha fazla bağlantı açar. Worker sayısı arttıkça, veritabanı tarafında yüzlerce bağlantı oluşabilir ve bu da bellek tüketimi ile context switch maliyetini artırır. PgBouncer gibi hafif bir bağlantı havuzu araya konarak:

• Veritabanına giden gerçek bağlantı sayısını sınırlayabilirsiniz.
• Kısa ömürlü bağlantıların maliyetini azaltabilirsiniz.
• Uygulama katmanını yeniden başlatırken veritabanı bağlantılarını kesmemiş olursunuz.

PgBouncer’ı uygulama VPS’inde veya PostgreSQL VPS’i ile aynı sunucuda konumlandırmak mümkündür; çoğu senaryoda DB tarafında konumlandırmak daha yalın bir yapı sağlar.

PostgreSQL Replikasyon: Okuma Yükünü Bölmek ve Felaket Kurtarma

Odoo/ERPNext’te çoğu iş yükü yazma ağırlıklıdır; ancak raporlama, BI araçları ve dış entegrasyonlar ciddi okuma yükü oluşturabilir. PostgreSQL’in streaming replication özelliğiyle bir veya daha fazla read-replica kurarak:

• Raporlama ve analitik sorguları replica üzerine yönlendirebilirsiniz.
• Ana veritabanı üzerindeki okuma yükünü azaltırsınız.
• Felaket durumunda, replica’yı kısa sürede yeni master’a terfi ettirebilirsiniz.

Burada devreye RPO/RTO hedefleri girer. KOBİ’ler için gerçekçi RPO/RTO nasıl belirlenir, hosting tarafında ne kadarını karşılayabilirsiniz gibi soruları daha detaylı olarak RPO/RTO ve felaket kurtarma rehberinde anlattık. Odoo/ERPNext için de aynı prensipler geçerlidir.

Yedekleme Stratejisi: Odoo ve ERPNext Verinizi Nasıl Gerçekten Korursunuz?

Odoo veya ERPNext kurulumunuz ne kadar hızlı ve ölçeklenebilir olursa olsun, sağlam bir yedekleme stratejisi yoksa gerçek anlamda güvende değilsiniz. Özellikle PostgreSQL gibi transactional bir veritabanı söz konusu olduğunda, “haftada bir tam yedek” mantığı artık kabul edilebilir değil.

3-2-1 Kuralı, Immutable Yedekler ve Ransomware Riskine Karşı Korunma

Modern yedekleme stratejilerinin temelinde 3-2-1 kuralı vardır:

• Verinizin en az 3 kopyası olmalı (1 üretim, 2 yedek).
• Bu kopyalar en az 2 farklı ortamda tutulmalı (örneğin VPS diski + harici Object Storage).
• En az 1 kopya farklı bir lokasyonda veya air-gap’e yakın bir ortamda saklanmalı.

Ransomware ve benzeri saldırılara karşı, salt 3-2-1 yetmez; yedeklerin immutable (değiştirilemez) şekilde saklanması, yazma korumalı period’lar ve düzenli geri dönüş testleri de gerekir. Bu konuyu hem cPanel/VPS hem de genel altyapı perspektifinden ransomware’a dayanıklı yedekleme stratejisi makalemizde detaylandırdık; Odoo/ERPNext için de birebir geçerlidir.

PostgreSQL İçin Mantıksal ve Fiziksel Yedekler

PostgreSQL’i yedeklerken iki temel yaklaşım vardır:

• Mantıksal yedekler (pg_dump/pg_dumpall):
  • Tablo ve şema bazlı; daha esnek, ancak büyük veritabanlarında yavaş olabilir.
  • Şema değişikliklerinde (upgrade, migration) granular geri dönüş imkânı sağlar.
• Fiziksel yedekler (pg_basebackup, pgBackRest vb.):
  • Veritabanı klasörünün bire bir kopyasını alır.
  • Büyük veritabanlarında daha hızlı ve verimli çalışır.
  • Point-in-Time Recovery (PITR) ile belli bir ana geri dönüş imkânı sunar.

Odoo/ERPNext kurulumlarında, genellikle şu kombinasyon iyi çalışır:

• Günlük 1 tam fiziksel yedek (örneğin pgBackRest ile).
• 10–15 dakikada bir WAL arşivleme ve PITR imkânı.
• Haftalık veya kritik sürüm geçişlerinden önce mantıksal (pg_dump) yedekler.

PgBackRest ve WAL arşivlemeyi VPS ortamında nasıl kurabileceğinizi adım adım anlattığımız PostgreSQL yedekleme ve PITR rehberi, Odoo/ERPNext kurulumlarınıza doğrudan uygulanabilir.

Snapshot Tabanlı Yedekler ve Uygulama-Tutarlılık

Birçok VPS altyapısında, disk seviyesinde snapshot almak mümkündür. Snapshot yedekler hızlıdır ve tüm diskin anlık görüntüsünü alır; ancak veritabanı açısından bakıldığında “uygulama-tutarlı” olup olmaması önemlidir.

• Crash-tutarlı snapshot: Elektrik kesintisi yaşanmış gibi bir anlık görüntü; PostgreSQL genellikle toparlar ama her zaman risk barındırır.
• Uygulama-tutarlı snapshot: Snapshot öncesi veritabanı kısa süreliğine dondurulur (örneğin fsfreeze veya LVM snapshot ile), böylece disk üzerinde tutarlı bir durum yakalanır.

Odoo/ERPNext için ideal yaklaşım, snapshot’ı PostgreSQL seviyesindeki yedeklere ek bir katman olarak kullanmaktır; tek başına snapshot’a güvenmek yerine, düzenli mantıksal/fiziksel yedeklerle birlikte düşünmek gerekir.

Yedeklerin Saklanması, Şifrelenmesi ve Test Edilmesi

Yedek almak işin yarısı bile değil; asıl kritik kısmı saklama, şifreleme ve geri dönüş testleridir:

• Depolama: Yedekleri üretim VPS’inden ayrı bir VPS’e veya Object Storage’a kopyalayın. Aynı diskte tutulan yedek, yedek değildir.
• Şifreleme: Özellikle kişisel veri içeren ERP veritabanlarını yedeklerken, disk veya obje seviyesinde şifreleme kullanın.
• Saklama süreleri: KVKK/GDPR gerekliliklerinize göre saklama süresini belirleyin; gereğinden fazla veri tutmak da risk yaratabilir.
• Geri dönüş testi: Belirli aralıklarla test ortamına geri yükleme yaparak, yedeğin gerçekten çalıştığını doğrulayın.

DCHost’ta gördüğümüz en büyük hatalardan biri, yıllarca hiç test edilmemiş yedeklere güvenmek. Oysa bir kez bile test restore yapıldığında, eksik configuration, bozuk dump veya yanlış şifreleme anahtarları hemen ortaya çıkıyor.

İzleme, Kapasite Planlama ve DCHost Tarafında Pratik Öneriler

Odoo ve ERPNext için doğru mimariyi kurduktan sonra iş bitmiyor; sistemin zamanla nasıl davrandığını gözlemek ve gerektiğinde küçük ayarlamalar yapmak gerekiyor.

İzlenecek Temel Metrikler

VPS üzerinde düzenli takip etmeniz gereken başlıca göstergeler:

• CPU kullanımı: Özellikle business saatlerinde sürekli %70–80 bandındaysa, vCPU arttırmayı veya worker sayısını optimize etmeyi düşünün.
• RAM kullanımı ve swap: RAM sürekli dolu, swap kullanımı artıyorsa, PostgreSQL/uygulama ayarlarını gözden geçirin veya RAM yükseltin.
• Disk IOPS ve latency: PostgreSQL için kritik. NVMe disklerde dahi anormal gecikmeler görüyorsanız sorgu optimizasyonu ve indekslemeye bakmak gerekir.
• PostgreSQL özel metrikleri: slow query log, autovacuum istatistikleri, bloat oranları.

PostgreSQL özelinde autovacuum ve bloat yönetimini detaylı anlattığımız autovacuum tuning rehberi, özellikle büyüyen Odoo/ERPNext veritabanlarında hayat kurtaran bir kaynak.

Staging Ortamı ve Güvenli Güncellemeler

Odoo veya ERPNext sürüm güncellemeleri, modül ekleme/çıkarma işlemleri ve yapılandırma denemeleri için staging/test ortamı kullanmak büyük fark yaratır. DCHost üzerinde sık uyguladığımız pratik yaklaşım şöyle:

• Canlı veritabanının belirli bir anlık kopyasını staging VPS’ine geri yükleyin.
• Yeni modülleri, özelleştirmeleri ve performans ayarlarını burada deneyin.
• İşe yarayan değişiklikleri, planlı bir bakım penceresinde canlı ortama taşıyın.

Böylece canlı ortamda sürprizlerle karşılaşmaz, yedek ve geri dönüş planınızı da pratikte sınamış olursunuz.

DCHost Tarafında Yaygın Mimariler

DCHost müşterilerinde sık gördüğümüz birkaç başarılı desen:

• Tek VPS + harici yedek: Küçük ekipler için maliyet–performans dengesi yüksek.
• Uygulama VPS + PostgreSQL VPS + Object Storage yedeği: 20–80 kullanıcı bandı için ideal, esnek ve güvenli.
• Dedicated PostgreSQL + çoklu uygulama VPS: Orta–büyük kurulumlar ve SaaS yapılar için hem performanslı hem geleceğe açık bir mimari.

Her üç modelde de ortak noktamız, yedeklerin mutlaka ayrı bir altyapıya (ayrı VPS veya Object Storage) taşınması ve düzenli geri dönüş testleriyle doğrulanması. Zaten bu bakış açısını, genel yedekleme stratejilerini anlattığımız 3-2-1 yedekleme stratejisi rehberinde de vurguluyoruz.

Sonuç ve Yol Haritası: Odoo/ERPNext İçin Sağlam Bir VPS Mimarisi Nasıl Kurulur?

Odoo ve ERPNext için doğru VPS mimarisini kurmak, tek seferlik bir karar değil; iş yükünüzle birlikte evrilen bir süreç. Ancak başlangıçta birkaç ana prensibe dikkat ederseniz, ileride büyük refaktörlere ihtiyaç duymadan, kontrollü ve öngörülebilir şekilde büyüyebilirsiniz:

• Küçük kurulumlarda bile CPU ve RAM’i çok kısıp performanstan feragat etmeyin; 2–4 vCPU ve en az 8 GB RAM genellikle iyi bir taban.
• PostgreSQL’i hafife almayın; veritabanı RAM ve disk IOPS’dan beslenir, NVMe ve doğru ayarlar fark yaratır.
• 20+ aktif kullanıcıya yaklaştığınızda, uygulama ve veritabanını ayırmayı ciddi şekilde düşünün.
• Yedekleme tarafında 3-2-1 kuralını, immutable yedekleri ve düzenli geri dönüş testlerini standart hale getirin.
• İzleme, loglama ve staging ortamı ile mimarinizi sürekli iyileştirin.

DCHost olarak hem küçük KOBİ kurulumlarında hem de çok kiracılı SaaS projelerinde Odoo ve ERPNext altyapılarını yıllardır yönetiyoruz. İhtiyacınız tek VPS’te tüm sistemi koşturmak da olsa, PostgreSQL’i dedicated sunucuya taşıyıp uygulama katmanını çoklu VPS ile ölçeklemek de olsa, mimari tasarım, kapasite planlama ve yedekleme kurgusu konusunda ekibimizle birlikte yanınızdayız. Mevcut kurulumunuzu gözden geçirmek veya yeni bir projeye başlamadan önce mimari taslak çıkarmak isterseniz, DCHost destek ekibine birkaç satırlık özetle ulaşmanız yeterli; kalanını beraber şekillendiririz.