ERP için Sunucu Boyutlandırması: Doğru Şekilde Nasıl Yapılır?

ERP için sunucu boyutlandırma, teknik gibi görünen ancak önemli iş sonuçları doğuran kararlardan biridir. Sunucunuzun boyutu küçükse ilk günden itibaren yavaş sayfa yüklemeleri, yoğun kullanım sırasında zaman aşımları ve eş zamanlı yük altında veritabanı kilitlenmeleri gibi performans şikayetleriyle karşılaşırsınız. Boyutunu büyüttüğünüzde çoğunlukla boşta duran altyapıya gerekenden çok daha fazlasını harcarsınız.

Çoğu ERP uygulaması, sunucu boyutlandırmasını iki yönden birinde yanlış yapar: ERP'nin veritabanı yoğunluğunu hesaba katmadan "bu sadece bir web uygulamasıdır" sezgisine dayalı olarak boyutlandıran kendine aşırı güvenen BT ekipleri veya makul maliyetle uygun performans yerine her maliyette maksimum performans için kalibre edilmiş satıcı önerileri.

Bu kılavuz size ERP dağıtımları için sunucu boyutlandırma konusunda yapısal bir yaklaşım sunar: kaynak gereksinimlerini yönlendiren temel değişkenler, farklı kullanıcı sayılarında büyük ERP platformları için özel boyutlandırma yönergeleri ve özel durumunuzu modellemek için ECOSIRE'ın ücretsiz Sunucu Boyutlandırma Hesaplayıcısının nasıl kullanılacağı.

Önemli Çıkarımlar

ERP, tipik web uygulamalarından çok daha fazla veritabanı yoğunluğuna sahiptir — standart web sunucusu boyutlandırma kuralları geçerli değildir

CPU nadiren kısıtlamadır; RAM ve disk G/Ç, ERP iş yüklerinde neredeyse her zaman darboğazdır

Odoo, eş zamanlı çalışan işlem başına 2–4 GB RAM gerektirir; 50'den fazla kullanıcıya sahip üretim örnekleri için en az 16 GB

Veritabanı depolama IOPS gereksinimleri çoğu sunucu boyutlandırma çalışmasında önemli ölçüde hafife alınmaktadır

Kağıt üzerinde eşdeğer görünen bulut örnekleri (aynı vCPU, aynı RAM) çok farklı G/Ç performansına sahip olabilir

Her zaman %30-40 boşluk payı ile en yüksek eşzamanlı yüke (ortalama yük değil) göre boyutlandırın

Özel kullanıcı sayınız ve ERP platformunuz için bir spesifikasyon oluşturmak için ECOSIRE'ın ücretsiz Sunucu Boyutlandırma Hesaplayıcısını kullanın

ERP Sunucu Boyutlandırması Neden Farklı?

Belirli önerilere dalmadan önce, ERP sunucusu boyutlandırmanın neden tipik bir web uygulamasına yönelik boyutlandırmadan daha dikkatli bir analiz gerektirdiğini anlamakta fayda var.

Veritabanı yoğunluğu: ERP sistemleri temelde işlem işleme sistemleridir. Her kullanıcı eylemi (satın alma siparişi oluşturma, fatura gönderme, envanteri taşıma) atomik olarak gerçekleştirilmesi gereken birden fazla veritabanı yazma işlemine neden olur. Veritabanı katmanı, büyük, normalleştirilmiş şemalar genelinde karmaşık ilişkisel sorguları, çoğunlukla birden fazla tablo birleşimi ve toplu hesaplamalarla yönetir. Bu, sayfa görüntüleme başına birkaç denormalize tablodan okunabilen bir içerik yönetim sisteminden veya bir pazarlama web sitesinden çok farklıdır.

Eşzamanlı kullanıcı yükleme kalıpları: ERP kullanıcı davranışı, tipik web uygulamalarından daha eşzamanlıdır. Bir tüketici web sitesinde, kullanıcılar seyrek etkileşimlerle bağımsız olarak gezinirler. Bir ERP sisteminde, aynı departmandaki birden fazla kullanıcı, yoğun saatlerde (ay sonu, gün sonu, vardiya kapanışı) siparişleri aynı anda işleyebilir. Bu eşzamanlı yazma modeli, tipik bir web uygulamasının asla karşılaşmayacağı bir veritabanı kilidi çekişmesi yaratır.

Rapor oluşturma iş yükü: ERP raporları (özellikle finansal raporlar, envanter yaşlandırma ve talep tahmini), 30-120 saniye boyunca çalışabilen ve yürütme sırasında önemli miktarda CPU ve G/Ç tüketen karmaşık, çok tablolu sorguları yürütür. Üç finans personeli ay sonu kapanış raporlarını aynı anda çalıştırdığında ortaya çıkan yük artışı ciddi olabilir.

Oturum durumu ve çalışan işlemleri: Odoo, her aktif kullanıcı bağlantısı için oturum durumunu koruyan Python çalışan işlemlerini özel olarak çalıştırır. Her çalışan işlemi, kararlı durumda yaklaşık 200-400 MB, yoğun rapor yürütme sırasında ise 1 GB'a kadar RAM tüketir. Sunucunun, diske geçiş yapmadan tüm aktif çalışanları aynı anda çalıştırabilmesi için yeterli RAM'e ihtiyacı vardır; bir ERP veritabanı sunucusunda değişiklik yapmak, performansın ciddi şekilde düşmesine neden olur.

ERP Sunucu Boyutlandırmasında Temel Değişkenler

Dört değişken, ERP sunucusu kaynak gereksinimlerini diğerlerinden daha fazla etkiler:

1. Eş zamanlı kullanıcı sayısı (toplam kullanıcı sayısı değil)

Toplam kullanıcı sayısı, kaynak gereksinimlerinin zayıf bir göstergesidir. Doğru ölçüm, en yoğun eşzamanlı kullanıcılardır: günün en yoğun döneminde aynı anda sisteme aktif olarak istekte bulunan kullanıcıların sayısı.

Toplam kullanıcı sayısından en yüksek eşzamanlı kullanıcıların tahmin edilmesi:

Normal çalışma saatlerine sahip ofis tabanlı ERP: Toplam kullanıcıların %15-25'i en yoğun saatlerde eşzamanlıdır
Çoklu vardiyalarla üretim: Toplam kullanıcıların %25-35'i eş zamanlı (vardiya değişiminde zirve)
Zaman dilimleri arasında dağıtılmış işlemler: daha düşük yoğun eşzamanlılık ancak daha uzun yoğun süreli
Ay sonunda finansman ağırlıklı kullanım: kapanış dönemlerinde eşzamanlı olarak %40-50'ye geçici artış

Normal ofis tabanlı kullanıma sahip 100 kullanıcılı bir Odoo dağıtımı için, tipik zirvede 15-25 eşzamanlı kullanıcıyı planlayın ve ay sonunda 40-50 eşzamanlı kullanıcıyı planlayın. Bu, toplam 100 kullanıcıyı değil, boyutlandırma hesaplamanızı yönlendirmelidir.

2. İşlem hacmi ve işlem karmaşıklığı

Yüksek işlem hacimleri, veritabanı yazma yükünü eşzamanlı kullanıcılardan bağımsız olarak artırır. Günde 2.000 satınalma siparişini işleyen bir dağıtım şirketi, 100 kullanıcılı ancak düşük işlem hacmine sahip bir profesyonel hizmet firmasına kıyasla çok daha fazla veritabanı yazma I/O'su üretir. Benzer şekilde, karmaşık işlemler (ürün reçetesi tüketimini, envanteri, maliyet muhasebesini ve kalite kayıtlarını aynı anda güncelleyen iş emirlerinin imalatı), basit işlemlerden (iki defteri kebir hesabını güncelleyen bir yevmiye kaydı kaydı) daha fazla G/Ç üretir.

Kullanımdaki modülleri düşünerek işlem karmaşıklığınızı tahmin edin: üretim ve çoklu depo envanteri en karmaşık işlemleri oluşturur; basit muhasebe ve İK modülleri en basitini oluşturur.

3. Veritabanı boyutu ve büyüme oranı

Veritabanı boyutu, sorgu performansını iki şekilde etkiler: doğrudan (daha büyük tabloların taranması daha uzun sürer) ve dolaylı olarak (kullanılabilir RAM'i aşan çalışma kümeleri, önbellek eksikliklerine ve artan G/Ç'ye yol açar).

ERP veritabanları çoğu BT ekibinin beklediğinden daha hızlı büyüyor. 20 GB'lık bir başlangıç veritabanı, işlem geçmişi, belge ekleri ve denetim günlüklerinden normal bir büyüme ile iki ila üç yıl içinde 100 GB'a ulaşabilir. Depolama alanınızı yalnızca mevcut ihtiyaçlara göre değil, üç yıllık beklenen büyümeye göre boyutlandırın.

4. Entegrasyon ve API iş yükü

ERP'niz API aracılığıyla harici sistemlere (e-Ticaret platformu, 3PL sistemi, banka API'leri, pazar yeri bağlayıcıları) bağlanıyorsa bu entegrasyonlar, kullanıcı sayılarına yansıtılmayan ek sunucu yükü oluşturur. Her API çağrısı, ERP'nin uygulama katmanından ve veritabanından geçer; yüksek hacimli bir entegrasyon (saatte 1.000 sipariş senkronizasyon isteğini işler), 10-20 eşzamanlı kullanıcının yükünü karşılayabilir.

Platform ve Kullanıcı Sayısına Göre Boyutlandırma Yönergeleri

Odoo 19 Kurumsal

Odoo'nun mimarisi, her biri kullanıcı isteklerine hizmet eden çalışan süreçlerini (Odoo çalışanları) kullanır. Çalışan sayısı ve sunucu kaynaklarının eş zamanlı kullanıcı sayısıyla ölçeklendirilmesi gerekiyordu.

Odoo işçi hesaplaması:

Önerilen çalışanlar = (eşzamanlı kullanıcılar / 6) + 1, yuvarlanır
Her çalışan, kararlı durumda yaklaşık 300-500 MB RAM'e, yoğun raporlar sırasında ise 1 GB'a kadar ihtiyaç duyar
Cron çalışanları (arka plan işlemleri için) 2-4 ek çalışan ekler

Kullanıcı sayısına göre önerilen minimum özellikler:

Toplam Kullanıcı	En Yüksek Eşzamanlı	İşçiler	CPU (çekirdek)	RAM	SSD Depolama
10–25	3–6	3	4	8GB	100GB
25–50	6–12	4	4	16GB	200GB
50–100	12–25	6	8	32GB	300GB
100–200	25–50	10	16	64GB	500GB
200–400	50–100	18	32	128GB	1TB
400+	100+	30+	48+	256GB+	2 TB+

Odoo boyutlandırmasıyla ilgili önemli notlar:

Veritabanı (PostgreSQL) ve uygulama (Odoo çalışan işlemleri) ideal olarak 100 kullanıcıdan fazla ayrı sunucularda çalışır. Tek bir sunucuda birleştirilen veritabanı ve uygulama, RAM için rekabet eder.
PostgreSQL paylaşımlı belleği (active_cache_size), veritabanı sunucusu RAM'inin %50-75'ine ayarlanmalıdır.
PostgreSQL veri dizini için SSD depolama zorunludur; dönen disk, herhangi bir ERP veritabanında felaket performansa neden olur.
50 kullanıcının üzerindeki dağıtımlar için Odoo oturum depolaması için ayrı bir Redis sunucusu önerilir.

Microsoft Dynamics 365 İş Merkezi

SaaS dağıtım modeli kullanıldığında Business Central, Microsoft Azure altyapısında bulutta barındırılır; bu durumda sunucu boyutlandırması Microsoft tarafından yönetilir. Şirket içi dağıtımlar için:

Toplam Kullanıcı	En Yüksek Eşzamanlı	CPU (çekirdek)	RAM	SQL Sunucu RAM'i	Depolama
10–25	3–6	4	16GB	8GB	150GB
25–75	6–18	8	32GB	16GB	300GB
75–150	18–37	16	64GB	32GB	500GB
150–300	37–75	32	128GB	64GB	1TB

Şirket içi Business Central, veritabanı olarak PostgreSQL'den ayrı bir bellek yönetimi modeline sahip olan SQL Server'ı kullanır. Ayrılmış RAM'i SQL Server'ın arabellek havuzuna ayırın (max server memory ayarı aracılığıyla) - veritabanı sunucusu RAM'inin yaklaşık %75'i.

SAP Business One

SAP Business One şirket içinde (Windows veya HANA) veya SAP Business One Cloud üzerinde devreye alınır:

Toplam Kullanıcı	En Yüksek Eşzamanlı	CPU	RAM (SAP HANA)	RAM (SQL Sunucusu)	Depolama
En fazla 25	6–10	8 çekirdek	64GB	32GB	500GB
25–75	15–25	16 çekirdek	128GB	64GB	1TB
75–150	25–50	32 çekirdek	256 GB	128GB	2TB

SAP HANA (SAP Business One HANA sürümüyle kullanılan bellek içi veritabanı), çalışma kümesinin belleğe sığması gerektiğinden geleneksel disk tabanlı veritabanlarına göre çok daha yüksek RAM gereksinimlerine sahiptir. HANA'nın RAM gereksinimleri tartışılamaz; belleğin yetersiz kaldığı HANA çöker, bozulmaz.

Bulut Örneği Önerileri

AWS, Azure veya GCP'de ERP'yi kendi kendine barındırırken doğru örnek tipini seçmek önemli ölçüde önemlidir. Aynı vCPU ve RAM sayılarına sahip tüm bulut sunucuları, veritabanı iş yükleri için aynı performansı göstermez.

Odoo için AWS önerileri (birleşik uygulama+db, 100 kullanıcıdan az):

t3.xlarge (4 vCPU, 16 GB): Geliştirme ve küçük üretim (25 kullanıcı altı)
r6i.xlarge (4 vCPU, 32 GB): Küçük-orta ölçekli üretim (25–50 kullanıcı)
r6i.2xlarge (8 vCPU, 64 GB): Orta düzeyde üretim (50–100 kullanıcı)
r6i.4xlarge (16 vCPU, 128 GB): Büyük üretim (100–200 kullanıcı, toplam)

Odoo için AWS önerileri (bölünmüş uygulama/db, 100'den fazla kullanıcı):

Uygulama sunucusu: c6i.2xlarge (8 vCPU, 16 GB) — işlem açısından optimize edilmiş
Veritabanı sunucusu: r6i.4xlarge (16 vCPU, 128 GB) — bellek açısından optimize edilmiş
Veritabanı depolama: io2 EBS birimleri (sağlanan IOPS) — 3.000–6.000 IOPS sağlandı

Azure eşdeğerleri:

Uygulama sunucusu: Standard_F8s_v2 (8 vCPU, 16 GB)
Veritabanı sunucusu: Standard_E16s_v5 (16 vCPU, 128 GB)

GCP eşdeğerleri:

Uygulama sunucusu: c2-standard-8 (8 vCPU, 32 GB)
Veritabanı sunucusu: n2-highmem-16 (16 vCPU, 128 GB)

G/Ç performans tuzağı: AWS'deki standart EBS gp3 birimleri varsayılan olarak 3.000 IOPS sağlar. 50'den fazla eşzamanlı kullanıcıya sahip bir üretim ERP veritabanı için bu genellikle yetersizdir; özellikle de birden fazla karmaşık raporun aynı anda çalıştırıldığı ay sonu kapanışında. Veritabanı depolaması için en az 3.000 IOPS'nin sağlandığı io2 sağlanan IOPS birimlerini kullanın. Maliyet farkı önemlidir (gp3 için 0,065 ABD Doları/GB/ay, io2 için 0,125 ABD Doları/GB/ay artı sağlanan IOPS için 0,065 ABD Doları/IOPS/ay), ancak performans farkı da önemlidir.

Yüksek Kullanılabilirlik Mimarisi

Kesinti süresinin önemli iş etkisine sahip olduğu üretim ERP sistemleri için, tek sunucu arızalarına karşı dayanıklılık sağlayan yüksek kullanılabilirliğe sahip bir mimariyi düşünün.

Odoo için minimum HA mimarisi (100+ kullanıcı):

Bir yük dengeleyicinin arkasında iki uygulama sunucusu (yuvarlak veya sabit oturumlar)
Yedek kopyalı PostgreSQL birincil veritabanı (akış çoğaltma veya AWS RDS Multi-AZ kullanılarak)
Oturum depolaması için Redis kümesi (iki düğüm)
Odoo'nun dosya eki verileri için paylaşılan dosya depolama alanı (AWS EFS veya eşdeğeri)

Bu mimari, manuel müdahale gerektirmeden tek bir sunucu arızasına karşı dayanıklılık sağlar. Birincil PostgreSQL'den bekleme moduna geçiş otomatiktir (Patroni veya AWS RDS kullanılarak) ve genellikle 30-60 saniyede tamamlanır.

Tipik ERP için RPO ve RTO hedefleri:

Kurtarma Noktası Hedefi (maksimum veri kaybı): 5 dakika (senkron çoğaltmayla) ila 30 dakika (zaman uyumsuz çoğaltmayla)
Kurtarma Süresi Hedefi (maksimum kesinti süresi): Otomatik yük devretme için 30–60 saniye, manuel kurtarma için 15–30 dakika

ECOSIRE Sunucu Boyutlandırma Hesaplayıcısını Kullanma

ECOSIRE'ın /tools/server-sizing-calculator adresindeki ücretsiz Sunucu Boyutlandırma Hesaplayıcısı, yukarıda açıklanan hesaplama sürecini otomatikleştirir. Girişler:

ERP platformu seçimi
Toplam kullanıcı sayısı
Eş zamanlı en yüksek kullanıcı yüzdesi (veya kullanım senaryosuna dayalı otomatik tahmin)
İşlem hacmi (düşük, orta, yüksek, çok yüksek)
Entegrasyon sayısı ve hacmi (yok, temel, orta, yoğun)
Kullanılabilirlik gereksinimleri (tek sunucu, HA, olağanüstü durum kurtarma)
Bulut sağlayıcı tercihi (AWS, Azure, GCP veya şirket içi)

Çıkışlar:

Uygulama ve veritabanı katmanları için önerilen sunucu özellikleri
Tercih ettiğiniz sağlayıcıya özel bulut örneği önerileri
Aylık altyapı maliyet tahmini
Ne zaman yükseltme yapmanız gerekeceğini gösteren üç yıllık büyüme tahmini
Depolama IOPS gereksinimleri ve önerilen depolama katmanı

Hesaplayıcı, düzinelerce müşteri uygulamasında ECOSIRE'ın kendi üretim dağıtım verilerine göre kalibre edilmiştir; bu da tahminleri tek başına satıcı belgelerinden daha güvenilir hale getirir.

Sıkça Sorulan Sorular

Daha önce hiç ERP kullanmamışsak, eş zamanlı en yüksek kullanıcı sayısını nasıl tahmin edebilirim?

Geçmiş verileri olmayan yeşil alan uygulamaları için, normal ofis tabanlı dağıtım için başlangıç tahmini olarak toplam kullanıcıların %20'sini kullanın. Birden fazla vardiyanız varsa veya birden fazla zaman diliminde çalışıyorsanız %25-30'u kullanın. Daha sonra ilk iki yılda büyüme için %50 boşluk payı ekleyin. Normal ofis saatleri olan 100 kullanıcılı bir ERP için, tipik zirvede 20 eşzamanlı kullanıcıyı planlayın, 30 kullanıcı için hazırlık yapın ve altyapı değişikliği olmadan 40 kullanıcıya ulaşacak kapasiteyi oluşturun. Bu boşluk payı yaklaşımı, uygulamaya geçişten sonraki aylarda benimsenme iyileştiği için performans sorunlarını önler.

Odoo uygulamasını ve veritabanını aynı sunucuda mı yoksa ayrı sunucularda mı çalıştırmamız gerekiyor?

50 kullanıcının altındaki dağıtımlar için tek bir birleşik sunucu genellikle iyidir; bu ölçekteki uygulama ve veritabanı iş yükleri genellikle çakışmaz. 50-100 kullanıcı için karar, kullanım modellerine bağlıdır: Kullanıcı tabanı, önemli yoğun dönemler olmadan gün boyunca eşit şekilde dağıtılmışsa, birleşik sunucu yine de çalışabilir. Keskin zirveler varsa (ay sonu, vardiya kapanışı), ayrı uygulama ve veritabanı sunucuları daha iyi izolasyon sağlar. 100'den fazla kullanıcının ayrı sunucular kullanması şiddetle tavsiye edilir.

Odoo veritabanı için hangi depolama türünü kullanmalıyız?

PostgreSQL veri dizini için SSD depolama zorunludur; dönen disk (HDD), herhangi bir üretim ERP veritabanında kabul edilemez performansa neden olur. Bulut platformlarında, 50'den fazla eşzamanlı kullanıcınız varsa veritabanı depolaması için sağlanan IOPS SSD'yi (AWS io2, Azure Premium SSD v2, GCP Extreme Persistent Disk) kullanın. Genel amaçlı SSD (AWS gp3, Azure Standart SSD), eşzamanlı 25 kullanıcının altındaki geliştirme ve küçük üretim dağıtımları için kabul edilebilir.

Sunucu boyutlandırmamızda ne kadar boşluk payı oluşturmalıyız?

Normal operasyonlar için beklenen en yüksek yükünüzün üzerinde %30-40 oranında boşluk payı oluşturun ve ay sonu kapanışı veya yoğun satış sezonları gibi istisnai dönemler için %100 boşluk payı (en yüksek kapasitenin etkili bir şekilde iki katı) oluşturun. Bulut dağıtımları, bu kapasite için kalıcı olarak ödeme yapmadan istisnai dönemleri yönetmek için otomatik ölçeklendirmeyi kullanabilir; bu, sabit şirket içi altyapıya göre önemli bir maliyet avantajıdır.

Sonraki Adımlar

Özel dağıtımınıza yönelik bir spesifikasyon oluşturmak için ECOSIRE'nin /tools/server-sizing-calculator adresindeki ücretsiz Sunucu Boyutlandırma Hesaplayıcısını kullanın. Hesaplayıcı, bir AWS/Azure/GCP bulut sunucusu önerisinin ve bütçe planlaması için kullanabileceğiniz aylık bir altyapı maliyeti tahmininin çıktısını verir.

Bir Odoo uygulaması planlıyorsanız ve ECOSIRE'ın uygulamayla birlikte altyapı boyutlandırma ve kurulumunu da üstlenmesini istiyorsanız, altyapı planlaması her ECOSIRE uygulama görevine dahil edilir.

Server Sizing for ERP: How to Get It Right