Hızlı Özet: cTrader cBot ve FIX API tabanlı algoritmik alım-satım operasyonlarında slipaj riskini sıfıra indirmek ve tick kaybını önlemek için minimum 4 tahsisli vCPU (≥3.8 GHz, CPU Steal %st = 0.0), 8 GB ECC RAM ve 80 GB PCIe 4.0 NVMe depolamaya sahip donanımsal KVM mimarisi gereklidir. Emir iletimini LD4 (Londra) veya NY4 (New York) likidite merkezlerine <1.5 ms RTT eşiğinde tutmak adına 1 Gbps simetrik uplink, TCP_NODELAY bayrağı yapılandırılmış soketler ve çift yönlü FIX 4.4 / cTrader Open API protokol entegrasyonu zorunludur. Windows Server 2022 üzerinde koşan .NET runtime ortamının volatilite patlamalarında thread kilitlenmesi yaşamaması adına bu donanım taban sınır kabul edilmeli; deterministik yürütmeyi bozan kaynak paylaşımlı konteyner altyapılarından (LXC/OpenVZ) kesinlikle kaçınılmalıdır.
İçindekiler
- Algoritmik Forex Ticaretinde VDS Neden Hayatidir: Slippage ve Gecikme Analizi
- Veri Merkezi Seçimi: Londra (Equinix LD4) ve Frankfurt (FR2) Lokasyon Avantajı
- KVM VDS Donanım Gereksinimleri: Yüksek Saat Hızlı CPU ve Sıfır Steal Time
- Windows Server VDS Üzerinde cTrader Kurulumu ve Uzak Masaüstü (RDP) Ayarları
- cBot Stratejilerinin 7/24 Kesintisiz Çalışması İçin Windows Servis Ayarları
- Ağ Kesintilerine Karşı Yedekleme ve Acil Kurtarma Planı (Disaster Recovery)
- Sıkça Sorulan Sorular (SSS)
Algoritmik Forex Ticaretinde VDS Neden Hayatidir: Slippage ve Gecikme Analizi
Finansal piyasalarda algoritmik emir iletimi, mikro saniye ($\mu\text{s}$) ve milisaniye ($\text{ms}$) ölçeğinde gerçekleşen deterministik bir yarışmadır. Spot Forex ve CFD piyasalarında cTrader platformu üzerinden çalışan algoritmaların (cBots veya Open API / FIX Engine tabanlı istemciler) kârlılığı, yalnızca matematiksel modelin doğruluğuna değil, emrin piyasaya iletilme anındaki Limit Order Book (LOB) durumuna doğrudan bağlıdır. Standart bir ev veya ofis internet bağlantısında önemsiz görünen 30–50 ms seviyesindeki gecikmeler, yüksek volatilite anlarında sermaye erimesine yol açan kontrolsüz slippage (fiyat kayması) maliyetlerine dönüşür. cTrader VDS algoritmik ticaret altyapısında gecikmenin sıfıra yaklaştırılması ve jitter dalgalanmalarının elimine edilmesi, doğrudan PnL (kâr/zarar) tablosunu belirleyen birincil mühendislik parametresidir.
1. Emir İletim Şelalesi (Execution Waterfall) ve Slippage Mekaniği
Bir cBot ExecuteMarketOrder() çağrısı yaptığında veya FIX API üzerinden NewOrderSingle (35=D) mesajı gönderildiğinde, emir anlık olarak gerçekleşmez. Paket, aşağıdaki katmanlardan oluşan deterministik bir iletim şelalesinden geçer:
$$\text{Toplam İletim Gecikmesi} = T_{\text{client_stack}} + T_{\text{propagation}} + T_{\text{routing_hops}} + T_{\text{broker_gateway}} + T_{\text{matching_engine}}$$
[cBot / FIX Engine]
│ (T_client_stack: OS TCP/IP yığını + NIC gecikmesi: ~0.1 - 0.5 ms)
▼
[Yerel Ağ Arayüzü (NIC)]
│ (T_propagation + T_routing_hops: BGP rotası ve fiber yayılım: ~1.0 - 2.5 ms)
▼
[Likidite Sağlayıcı / Broker Gateway (LD4 / FR2)]
│ (T_broker_gateway: FIX ayrıştırma ve risk kontrolü: ~0.5 - 1.5 ms)
▼
[Eşleşme Motoru (Matching Engine) & LOB]
Bu süreç boyunca piyasadaki alış/satış derinliği dinamik olarak değişir. Slippage, talep edilen fiyat ($P_{\text{req}}$) ile eşleşme motorunun emri defterdeki likiditeyle doldurduğu ağırlıklı ortalama fiyat ($P_{\text{exec}}$) arasındaki farktır:
$$\text{Slippage (Pip)} = \frac{|P_{\text{exec}} - P_{\text{req}}|}{\text{Pip Boyutu}}$$
$$\text{Mali Kayıp} = (P_{\text{exec}} - P_{\text{req}}) \times \text{Hacim (Lot)} \times \text{Kontrat Büyüklüğü}$$
Broker likidite sağlayıcıları (LP - Liquidity Providers; örn. LMAX, Currenex, XTX Markets, Citadel) emir eşleştirme sunucularını Londra (Equinix LD4 - Slough), Frankfurt (Equinix FR2) ve New York (Equinix NY4) veri merkezlerinde barındırır. Eğer cTrader istemcisi Türkiye'deki yerel bir FTTH bağlantısından çalışıyorsa, ışığın fiber kablodaki yayılma hızı ($\sim 200.000\text{ km/s}$) ve aradaki 12–18 yönlendirici (BGP hop) nedeniyle fiziksel RTT (Round-Trip Time) minimum 45–65 ms bandındadır.
Merkez bankası faiz kararları, ABD Tarım Dışı İstihdam (NFP) veya TÜFE (CPI) verisi açıklandığı anda, LOB üzerindeki en iyi alış/satış kademeleri saniyede on binlerce kez güncellenir. 50 ms gecikmeyle ulaşan bir piyasa emri, hedeflenen kademedeki likidite tükendiği için derinlikteki 2. veya 3. kademeden eşleşir. EUR/USD paritesinde 10 Lotluk bir işlemde meydana gelen 1.8 piplik aleyhte slippage, tek bir işlemde anında 180 USD net kâr kaybı anlamına gelir.
2. Donanım Sanallaştırma Katmanı: Noisy Neighbor ve %st (CPU Steal Time) Riski
Gecikme yalnızca ağ mesafesiyle sınırlı değildir; işletim sistemi ve hipervizör katmanındaki mikro gecikmeler de emir süresini uzatır. cTrader platformu .NET Core / C# altyapısıyla çalışır ve her gelen tick verisinde OnTick() metodunu tetikler. Tick frekansı yüksek seanslarda (Londra/New York çakışması) saniyede 300–800 tick akışı gerçekleşir.
Geleneksel ucuz VPS sağlayıcılarında kullanılan OpenVZ/LXC tabanlı paylaşımlı sanallaştırma veya aşırı tahsis (oversubscription) uygulanmış KVM hipervizörlerde, aynı fiziksel CPU çekirdeğini onlarca farklı sanal makine paylaşır. Bu durum Linux ortamlarında CPU Steal Time (%st), Windows Server ortamlarında ise hipervizör bekleme kuyruğu (Ready Time / DPC Latency) olarak ortaya çıkar.
- %st > 0.5% olduğu senaryoda: Fiziksel işlemci komşu sanal makinelerin yüküyle meşgul olduğundan, sanal çekirdeğe işlem zamanı tahsis edemez. cTrader iş parçacığı (thread) gelen piyasa tick'ini işleyemez, tampon bellek (socket buffer) şişer ve cBot'un matematiksel hesaplama süresi 15–40 ms sarkar.
- Gereksinim: Deterministik emir iletimi için hipervizör seviyesinde %st = 0.0% garantisi zorunludur.
tropic.host KVM mimarisi, fiziksel CPU kaynaklarında agresif çekirdek izolasyonu (vCPU pinning) uygulayarak sıfır aşırı tahsis garantisi sunar. Yüksek saat frekansına sahip AMD EPYC ve Ryzen 9 işlemciler (4.5+ GHz), cBot indikatör zincirlerinin ve emir üretim lojiğinin mikrosaniye seviyesinde işlenmesini güvenceye alır.
3. Altyapı Karşılaştırma ve Benchmark Analizi
Farklı altyapı sınıflarının cTrader ile algoritmik işlem performansına etkisini gösteren ampirik kıyaslama tablosu aşağıda verilmiştir:
| Parametre / Metrik | Standart Ev/Ofis FTTH Bağlantısı | Paylaşımlı / Aşırı Tahsisli VPS | tropic.host Optimize KVM NVMe VDS |
|---|---|---|---|
| Broker Lokasyonuna Ping (Equinix LD4) | 48.0 – 72.0 ms | 8.0 – 25.0 ms | 0.8 – 2.1 ms (Doğrudan BGP Peering) |
| Gecikme Değişkenliği (Jitter) | ± 12.5 ms (Yüksek dalgalanma) | ± 6.2 ms (Kuyruk şişmesi) | ± 0.2 ms (Ultra-stabil iletim) |
| CPU Steal Time (%st) | Yok (Fiziksel PC ancak zayıf tek çekirdek) | %2.5 – %12.0 (Noisy Neighbor) | %0.0 (Garantili çekirdek tahsisi) |
| Disk Rastgele 4K QD1 Yazma IOPS | 800 – 2.500 IOPS (Tüketici SSD/SATA) | 1.200 – 4.000 IOPS (Sanal disk kısıtlaması) | > 50.000 IOPS (Kurumsal PCIe 4.0 NVMe) |
| Paket İletim Protokolü / Akış Kontrolü | Standart TCP Cubic (Bufferbloat riski) | Varsayılan TCP Cubic | TCP BBR v1/v2 (Tıkanıklık minimizasyonu) |
| Normal Piyasa Koşullarında Slippage | 0.4 – 1.1 pip | 0.2 – 0.5 pip | 0.0 – 0.1 pip (Sıfıra yakın) |
| Yüksek Volatiliteli Haber Anı Slippage | 2.2 – 5.5 pip | 1.4 – 3.2 pip | 0.2 – 0.6 pip (Maksimum likidite yakalama) |
| Aylık Slippage Maliyeti (100 Lot Hacim) | ~$1.800 – $3.500 USD Kayıp | ~$700 – $1.400 USD Kayıp | <$120 USD (Minimum teorik sapma) |
4. Ağ ve İşletim Sistemi Seviyesinde Düşük Gecikme Yapılandırması
Bir VDS üzerinde cTrader veya FIX API motoru çalıştırılırken varsayılan işletim sistemi ağ yığını ayarları finansal mikrosaniye gereksinimlerine göre optimize edilmemiştir. Ağ kuyruklarını daraltmak ve paket gecikmesini minimize etmek için aşağıdaki adımlar uygulanmalıdır.
4.1. Windows Server (cTrader Automate / Desktop) Ağ Yığını İnce Ayarı
cTrader doğrudan Windows üzerinde çalışıyorsa, TCP/IP yığınındaki Nagle algoritması devre dışı bırakılmalı ve ACK gecikmesi iptal edilmelidir. Bu optimizasyon, küçük boyutlu FIX veya cTrader paketlerinin kuyrukta bekletilmeden hatta anında aktarılmasını sağlar.
PowerShell'i yönetici olarak çalıştırın ve ağ bağdaştırıcısının arabirim indeksini (InterfaceIndex) bulun:
# Ağ bağdaştırıcı indeksini tespit et
Get-NetAdapter | Select-Object -Property Name, InterfaceIndex, InterfaceDescription
# TCP Auto-Tuning ve ECN yapılandırması
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global ecncapability=enabled
netsh int tcp set global timestamps=disabled
netsh int tcp set global rss=enabled
netsh int tcp set supplemental template=custom icw=10
Kayıt Defteri (Registry) üzerinden Nagle Algoritmasını devre dışı bırakmak için PowerShell üzerinden doğrudan ilgili ağ arabirimine parametreleri enjekte edin:
$adapterGuid = (Get-NetAdapter | Where-Object {$_.Status -eq "Up"}).InterfaceGuid
$registryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$adapterGuid"
# Gecikmesiz ACK ve Nagle devre dışı bırakma (TCP_NODELAY eşdeğeri)
New-ItemProperty -Path $registryPath -Name "TcpAckFrequency" -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path $registryPath -Name "TCPNoDelay" -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path $registryPath -Name "TcpDelAckTicks" -Value 0 -PropertyType DWord -Force
4.2. Linux Tabanlı FIX Gateway ve cTrader Open API İçin Çekirdek (sysctl) Optimizasyonu
Headless cTrader algoritmaları veya Docker konteynerlerinde barındırılan cTrader Open API / Node.js / Python / C++ FIX istemcileri Linux üzerinde çalıştırıldığında, /etc/sysctl.conf dosyasında bellek arabellekleri, soket kuyrukları ve TCP BBR tıkanıklık kontrol algoritması tanımlanmalıdır.
tropic.host altyapısında varsayılan olarak desteklenen BBR (Bottleneck Bandwidth and RTT), geleneksel paket kaybına dayalı TCP Cubic algoritmasının aksine bant genişliği şişmesini ve kuyruk gecikmesini (bufferbloat) engeller:
# /etc/sysctl.d/99-trading-latency.conf
# TCP BBR Tıkanıklık Kontrolü ve FQ Kuyruk Planlayıcısı
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# TCP Zaman Damgalarını ve Yavaş Başlatmayı Devre Dışı Bırakma
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_slow_start_after_idle = 0
# Soket Alış/Veriş Tampon Bellek Boyutları (Aşırı şişmeyi engelleme)
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
# TCP Soket Bellek Limitleri (Min - Varsayılan - Maks)
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 65536 4194304
# Bağlantı Kuyruk Limitleri (Backlog derinliği)
net.core.netdev_max_backlog = 10000
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192
# Fast Open Desteği
net.ipv4.tcp_fastopen = 3
# FIN Zaman Aşımı ve Keepalive Sıklığı (Ölü bağlantıları hızlı temizleme)
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
Yapılandırmayı yürürlüğe koymak için:
sysctl -p /etc/sysctl.d/99-trading-latency.conf
5. Yüksek Hızlı Tick Kaydı ve NVMe I/O Bağımlılığı
Algoritmik ticarette yalnızca emir gönderme değil, emrin piyasa koşullarıyla teyidi ve model validasyonu için her bir tick verisinin yerel diske (SQLite, DuckDB veya Flat binary file formatında) yazılması gerekir. Yüksek volatilite periyotlarında disk yazma gecikmesi (I/O latency spike), cBot'un tek iş parçacıklı (single-threaded) çalışan olay döngüsünü kilitler.
Standart bulut sunucularında ağ üzerinden bağlanan blok depolama (Ceph, iSCSI SAN) ünitelerinde fsync() çağrıları 10–50 ms blokajlara neden olabilir. Bu durum motorun yeni tick almasını engelleyerek slippage oluşturur.
Doğrudan anakarta PCIe veri yollarıyla bağlı kurumsal sınıf NVMe sürücüler kullanan tropic.host platformunda, 4K rastgele yazma gecikmeleri sub-millisecond (< 50 $\mu\text{s}$) seviyesindedir. Böylece arka planda yürütülen yoğun telemetri ve tick logging operasyonları, emir iletim iş parçacıklarının execution döngüsünde sıfır kilitlenme (zero write-stall) ile çalışmasını sağlar.
Veri Merkezi Seçimi: Londra (Equinix LD4) ve Frankfurt (FR2) Lokasyon Avantajı
Algoritmik emir iletiminde yerel çekirdek gecikmesi (kernel latency) ve NVMe I/O darboğazları bertaraf edildikten sonra, toplam icra süresini (execution turnaround time) belirleyen nihai fiziksel sınır ağ katmanıdır (Layer 1–Layer 3). cTrader VDS algoritmik ticaret altyapılarında emir paketi ağ arabirim kartından (NIC) çıktığı anda ışık hızının fiber optik kablo içerisindeki yayılma katsayısına ($n \approx 1.4682$, yaklaşık $4.9\,\mu\text{s}/\text{km}$) ve paketlerin geçtiği yönlendirici (router) sekmelerine (hop) tabi olur. Coğrafi olarak yanlış konumlandırılmış bir sunucudan işlem yapıldığında, hiçbir yazılımsal optimizasyon 30–50 ms seviyesindeki fiziksel RTT (Round-Trip Time) gecikmesini telafi edemez.
Perakende ve kurumsal FX/CFD piyasalarında likidite sağlayıcılarının (Tier-1 Bankalar, Non-Bank Market Makers ve ECN motorları) sunucu altyapıları küresel ölçekte iki ana finansal veri merkezinde kümelenmiştir: Londra (Equinix LD4, Slough) ve Frankfurt (Equinix FR2, Kleyerstraße). cTrader platformunun mimari sahibi olan Spotware Systems'ın ticaret sunucuları, ECN köprüleri (oneZero, PrimeXM) ve emir eşleştirme motorları (matching engines) doğrudan bu iki kampüsün içerisindeki kafeslerde (cage) ya da bu merkezlere doğrudan karanlık fiber (dark fiber) ile bağlı metro hatlarında çalışır.
+-------------------------------------------------------------------------+
| FINANSAL EKOSISTEM VE AG TOPOLOJISI |
+-------------------------------------------------------------------------+
[ tropic.host KVM VDS ]
│ (10 Gbps Uplink / TCP BBR / Direct BGP)
├─── < 0.8 - 1.5 ms ────> [ Equinix LD4 (Slough, Londra) ]
│ ├── LMAX Exchange Engine
│ ├── Currenex / State Street
│ └── cTrader Spotware Live Proxy Nodes
│
└─── < 0.9 - 1.8 ms ────> [ Equinix FR2 (Frankfurt am Main) ]
├── Deutsche Börse / Eurex
├── 360T ECN / Deutsche Bank
└── FX / CFD Broker FIX Gateways
Finansal Veri Merkezlerinin Karşılaştırmalı Mimarisi
cTrader tabanlı brokerların likidite havuzları tek bir noktada homojen dağılmaz. Kurulacak cBot stratejisinin işlem yaptığı enstrüman sınıfına göre hedef veri merkezi seçilmelidir:
- Equinix LD4 (Londra - Slough):
- Odak: Spot FX, Majör/Minör döviz çiftleri, Değerli Metaller (XAU/USD, XAG/USD) ve Kripto türevleri.
- Likidite Bileşenleri: LMAX Exchange, XTX Markets, Citadel Securities, Jump Trading, FastMatch (Euronext FX).
- cTrader Altyapısı: Spotware'in ana proxy ve FIX API sonlandırma uç noktalarının (Live Server cluster) ezici çoğunluğu LD4 ve komşu LD5/LD6 tesislerindedir.
- Equinix FR2 (Frankfurt am Main):
- Odak: Avrupa Hisse Senedi Endeksleri (GER40/DAX, EU50), Enerji Emtiaları (Brent, WTI) ve tahvil vadeli işlemleri.
- Likidite Bileşenleri: Eurex, Deutsche Börse, 360T, Commerzbank ve BNP Paribas FX likidite motorları.
- cTrader Altyapısı: Birçok AB regülasyonuna tabi broker, emir doğrulama ve veri depolama birimlerini GDPR ve BaFin uyumluluğu nedeniyle doğrudan FR2 üzerinde barındırır.
Doğru lokasyonda konuşlandırılan bir VDS ile brokerın FIX/Open API ağ geçidi arasındaki gidiş-dönüş süresi 1.0 – 2.0 ms bandına iner. Buna karşılık, örneğin Türkiye veya Doğu Avrupa lokasyonlu bir sunucudan LD4 üzerindeki bir cTrader sunucusuna gönderilen TCP paketleri ortalama 35–55 ms gecikmeye uğrar; yüksek volatilite anlarında bu fark kayma (slippage) maliyetini 1–3 pip artırarak algoritmik avantajı yok eder.
BGP Yönlendirme, IXP Katılımı ve Ağ Rotası Analizi
Düşük gecikmeli emir iletimi yalnızca fiziksel mesafeye değil, sunucunun internete çıktığı Otonom Sistem Numarası (ASN) üzerinden kurulan BGP (Border Gateway Protocol) anonslarının kalitesine bağlıdır. Kalitesiz barındırma sağlayıcıları maliyet düşürmek için trafiği ucuz, yüksek gecikmeli ve aşırı yüklenmiş transit operatörler üzerinden aktarır. Bu durum paketlerin rota üzerinde gereksiz sapmalara (örneğin Frankfurt'tan Londra'ya gidecek paketin Amsterdam ve Paris üzerinden dolaşması) ve bufferbloat kaynaklı kuyruk gecikmelerine uğramasına yol açar.
Ağ yolunun (network path) kararlılığını ve paket gecikmesini haritalandırmak için ICMP yerine doğrudan TCP SYN paketleriyle çalışan yüksek çözünürlüklü tanı araçları kullanılmalıdır:
# Broker FIX API uç noktasına doğru katman-3/katman-4 rota ve jitter denetimi
# -T: TCP SYN paketleri kullan, -p: Hedef FIX portu (genellikle 5201, 5202 veya 443)
mtr --tcp --port 5201 --report --report-cycles 100 --interval 0.05 --aslookup live-ld4.spotware.com
Tipik bir kurumsal seviye mtr çıktısında aranması gereken telemetri değerleri:
HOST: node01.tropic.host Loss% Snt Last Avg Best Wrst StDev
1. AS58299 gw.tropic.host 0.0% 100 0.3 0.3 0.2 0.5 0.1
2. AS1299 arest-b1.telia.net 0.0% 100 0.8 0.8 0.7 1.1 0.1
3. AS1299 ldn-b3-link.ip.twelve 0.0% 100 1.1 1.2 1.0 1.4 0.1
4. AS24115 equinix-ld4.slough.net0.0% 100 1.3 1.4 1.2 1.6 0.1
Burada kritik metrik StDev (Standart Sapma / Jitter) sütunudur. StDev değerinin < 0.2 ms olması, ara yönlendiricilerde paket kuyruğu oluşmadığını gösterir. Paket kaybı (Loss%) sıfır olmalıdır; TCP tabanlı FIX ve Open API oturumlarında %0.1'lik bir paket kaybı bile TCP yeniden iletim (retransmission) mekanizmasını tetikleyerek ilgili emrin iletimini 200 ms (RTO başlangıç değeri) geciktirir.
Soket seviyesindeki gecikmeyi teyit etmek için Linux çekirdeğinin SO_TIMESTAMPING desteğini kullanan veya ham TCP soketi açan nping komutuyla SYN-ACK yanıt süreleri milisaniyenin onda biri hassasiyetinde ölçülmelidir:
nping --tcp -p 443 -c 20 --delay 100ms live-ld4.spotware.com
Düşük Gecikmeli Ağ İletimi İçin Linux Çekirdek Arabirim Optimizasyonu
VDS seviyesinde virtio ağ kartının işletim sistemi kuyruklarıyla eşzamanlı çalışması ve context switch maliyetlerini düşürmek için ağ arabirim yapılandırması optimize edilmelidir.
Ağ kartı RX/TX halka tamponlarının (ring buffers) maksimum donanımsal limite çekilmesi:
# Geçerli ve maksimum tampon boyutlarını kontrol et
ethtool -g eth0
# Halka tamponlarını maksimum kapasiteye (örn. 4096) ayarla
ethtool -G eth0 rx 4096 tx 4096
Ağ kesmelerinin (IRQ) tek bir vCPU çekirdeğinde darboğaz yaratmasını engellemek ve yükü çekirdeklere dağıtmak için irqbalance servisinin cTrader botunun izole edildiği çekirdekleri hariç tutacak şekilde yapılandırılması gerekir. /etc/default/irqbalance dosyasında IRQBALANCE_BANNED_CPUS maskesi tanımlanarak, ticaret botunun çalıştığı çekirdek ağ kesmesi işleme yükünden muaf tutulur:
# Hexadecimal maske: 2. ve 3. çekirdekleri (vCPU 1 ve vCPU 2) IRQ dağıtımından muaf tut
# CPU 0: 0001, CPU 1: 0002, CPU 2: 0004 -> Banned mask: 00000006
echo 'IRQBALANCE_BANNED_CPUS="00000006"' >> /etc/default/irqbalance
systemctl restart irqbalance
tropic.host Altyapısında Doğrudan IXP ve BGP Avantajı
tropic.host platformunda barındırılan KVM tabanlı bulut sunucuları, Londra ve Frankfurt finansal merkezlerindeki ana Internet Değişim Noktalarına (DE-CIX Frankfurt, LINX London) ve Arelion (eski adıyla Telia Carrier), Lumen gibi Tier-1 taşıyıcılara doğrudan 1–10 Gbps fazlalıklı (redundant) omurgalarla bağlıdır.
Bu ağ mimarisi sayesinde: * Asimetrik Rota Engellemesi: Sunucudan çıkan paket ile broker ağından dönen ACK paketleri aynı BGP rotasını takip eder; gidiş-dönüş rotalarındaki asimetri ve faz farkı sıfırlanır. * Sıfır CPU Çalma Oranı (%st = 0.0): KVM hipervizöründe işlemci çekirdekleri aşırı tahsis edilmediğinden (no overcommit), gelen ağ paketleri virtio arabiriminden doğrudan çekirdek soketine gecikmesiz işlenir. * TCP BBR Hız Kontrolü: Ağ yolundaki anlık paket kayıplarında TCP pencere boyutunu dramatik şekilde daraltan eski CUBIC algoritması yerine, hat kapasitesini ve RTT tabanını gerçek zamanlı izleyen TCP BBR varsayılan olarak devrededir.
Frankfurt veya Londra lokasyonlu bir tropic.host KVM VDS üzerinde koşan cTrader motoru; ECN eşleştirme motorlarına doğrudan 1.2–1.8 ms bandında stabil BGP bağlantısı kurarak emir iletim zincirindeki tüm ağ gecikmelerini donanımsal ve coğrafi sınırlarına indirger.
KVM VDS Donanım Gereksinimleri: Yüksek Saat Hızlı CPU ve Sıfır Steal Time
cTrader Automate (.NET CLR tabanlı cBot altyapısı) mimarisi gereği, gelen piyasa derinliği (Depth of Market - DoM) ve fiyat tiklerini (ticks) sembol bazında tekil bir iş parçacığı (single-threaded execution thread) üzerinde senkronize bir döngüde işler. Her OnTick() ve OnBar() çağrısı; gösterge (indicator) hesaplamaları, risk yönetimi kontrolleri ve emir tetikleme mantığını aynı CPU çekirdeğinde ardışık olarak koşturur. Bu yazılımsal gerçeklik, cTrader VDS algoritmik ticaret altyapılarında çok çekirdekli düşük frekanslı işlemciler yerine, tek çekirdek saat hızı (Single-Core IPC ve Boost Clock) 4.5 GHz ve üzeri olan donanım mimarilerini zorunlu kılar.
Tek Çekirdek Performansı ve İş Parçacığı Tıkanması (Thread Starvation)
Algoritmik ticarette karşılaşılan kayma (slippage) problemlerinin önemli bir bölümü ağ gecikmesinden değil, sanal makinenin CPU çekirdeğinde oluşan kuyruk birikmesinden (tick backlog) kaynaklanır. Volatilitenin tavan yaptığı anlarda (faiz kararları, NFP verileri veya jeopolitik kırılmalar) saniyede gelen fiyat güncellemesi sayısı 150–200 tikten 4.000–6.000 tik seviyesine fırlar.
Düşük taban frekansına sahip (örneğin 2.2–2.4 GHz bandındaki eski nesil paylaşımlı işlemciler) bir sanal sunucuda OnTick() fonksiyonunun çalışma süresi 300 mikrosaniyeyi aştığında, işlemci döngüleri bir sonraki fiyat paketini işlemek için yetişemez. Olay kuyruğu şişer, emir iletimi gecikir ve algoritma piyasanın milisaniyelerce önceki eski fiyatına emir göndererek ciddi bir negatif kayma ile karşılaşır.
Yüksek frekanslı AMD Ryzen 9 (7950X, 9950X) veya yüksek saat hızlı AMD EPYC / Intel Xeon işlemcilerde ise işlemci döngüsü başına düşen talimat sayısı (IPC) ve L3 önbellek (cache) mimarisi optimize edilmiştir. 32 MB ile 64 MB arasında değişen L3 önbellek havuzları, cBot algoritmasının bellek üzerindeki veri yapılarına doğrudan önbellekten erişmesini sağlayarak RAM veri yolundaki (bus latency) tipik 60–80 ns gecikmeyi 10–12 ns seviyesine çeker.
CPU Steal Time (%st) Analizi ve Hipervizör Overcommit Tehlikesi
Paylaşımlı VPS ve kontrolsüz sanallaştırma mimarilerinde sağlayıcılar, fiziksel bir çekirdeğe birden fazla sanal vCPU bağlar (vCPU overcommitment: 1:3 veya 1:5 oranları). Bu durum, komşu sanal sunuculardan biri yoğun yük altına girdiğinde işlemcinin zaman dilimleyicisinin (time-slice) diğer sanal makinelerden çalınmasına neden olur. İşletim sisteminde bu durum CPU Steal Time (%st) metriği ile izlenir.
Algoritmik ticaret yapan bir KVM sunucuda %st değerinin %0.1 seviyesinin üzerine çıkması dahi kabul edilemez. Steal time anında sanal çekirdek donanımsal olarak duraklatılır (halt state); bu esnada ağ kartından gelen TCP paketleri işlenemez ve soket tamponlarında (socket buffer) birikir.
Sunucunun anlık CPU çalma oranını ve çekirdek bazlı gecikmelerini doğrulamak için terminal üzerinden mpstat aracıyla her çekirdeğin durumu denetlenmelidir:
# sysstat paketini kur ve her saniye tüm vCPU çekirdeklerini analiz et
apt-get install -y sysstat
mpstat -P ALL 1 10
Ekrana gelen tabloda %usr, %sys ve en önemlisi en sağdaki sütunda yer alan %steal değerleri incelenmelidir:
14:15:02 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
14:15:03 all 8.12 0.00 2.45 0.00 0.00 0.15 0.00 0.00 89.28
14:15:03 0 12.40 0.00 3.10 0.00 0.00 0.30 0.00 0.00 84.20
14:15:03 1 3.84 0.00 1.80 0.00 0.00 0.00 0.00 0.00 94.36
tropic.host altyapısında barındırılan KVM tabanlı yüksek performanslı VDS örneklerinde işlemci çekirdekleri 1:1 fiziksel çekirdek eşleşmesi (dedicated compute cores) ile tahsis edilir. Bu sayede hipervizör seviyesinde CPU overcommit tamamen devre dışı bırakılarak %steal oranı kesintisiz %0.0 seviyesinde sabit tutulur.
Donanımsal Zaman Kaynağı (Clocksource) Doğrulaması
cTrader platformunun milisaniye altı zaman damgalarını (microsecond timestamps) hatasız işleyebilmesi için Linux ve Windows çekirdeklerinin hipervizörden aldığı zamanlayıcı sinyali kritik önemdedir. Yanlış yapılandırılmış KVM hipervizörlerinde kullanılan yazılımsal saatler (hpet veya kararsız acpi_pm), sistem çağrısı (gettimeofday, clock_gettime) başına mikro saniyelik ek gecikmeler bindirir.
Sunucuda donanımsal Invariant TSC (Time Stamp Counter) mekanizmasının devrede olduğu şu komutla teyit edilmelidir:
# Mevcut ve desteklenen zaman kaynaklarını kontrol et
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Çıktıda tsc veya KVM'e optimize edilmiş kvm-clock görülmelidir. Eğer sistem varsayılan olarak hpet kaynağına düşmüşse, çekirdek boot parametrelerine tsc=reliable clocksource=tsc direktifleri eklenmelidir.
Bellek (RAM) Mimarisi ve Garbage Collection Baskısının Azaltılması
cTrader Automate, .NET çalışma ortamında Garbage Collector (GC) mekanizmasına tabidir. cBot her yeni tikte yüzlerce geçici nesne (fiyat dizileri, teknik analiz gösterge sonuçları, order nesneleri) üretir. Bu nesneler Gen 0 ve Gen 1 bellek alanlarında hızla birikir.
Yetersiz RAM tahsis edilen bir VDS üzerinde işletim sistemi takas alanına (swap) başvurduğu anda, bellek erişim süreleri nanosaniyelerden milisaniyelere çıkarak ticaret motorunu kilitler.
- Swap Belleği Kısıtlama ve Bellek Kilitleme: Algoritmik ticaret sunucusunda swap mekanizması tamamen kapatılmalı ya da çekirdeğin diske yazma eğilimi minimuma indirilmelidir:
```bash # Swap kullanım eğilimini minimuma çek sysctl -w vm.swappiness=1 echo "vm.swappiness=1" >> /etc/sysctl.conf
# Bellek yetersizliğinde OOM Killer'ın trade motorunu rastgele öldürmesini engelle sysctl -w vm.overcommit_memory=1 echo "vm.overcommit_memory=1" >> /etc/sysctl.conf ```
- Transparent HugePages (THP) Yönetimi: Veritabanı ve anlık bellek tahsis eden cTrader/Docker konteynerlerinde Linux çekirdeğinin 2MB boyutundaki HugePage sayfalarını arka planda birleştirmeye çalışması (khugepaged), bellek ayırma çağrılarında (malloc/mmap) gecikme patlamalarına (latency spikes) yol açar. Yüksek hızlı ticaret sunucularında THP modu
madvisemoduna alınmalıdır:
bash echo madvise > /sys/kernel/mm/transparent_hugepage/enabled echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
NVMe Disk Optimizasyonu: I/O Wait Darboğazını Yok Etme
Algoritmik ticaret altyapılarında disk operasyonları genellikle göz ardı edilir; ancak cTrader işlem günlüğü (trade log), emir yürütme kayıtları, yerel SQLite/tick veritabanı yazımları ve Windows sayfalama dosyaları sürekli diske erişir.
Sıradan SATA SSD veya paylaşımlı ağ depolama (NFS/Ceph SAN) mimarilerinde diske veri yazılırken oluşan I/O Wait (%wa), CPU çekirdeğini diskin yanıt vermesini beklerken boşta kilitler. O anda piyasada gelen fiyat verisi CPU'ya ulaşamaz.
Bu darboğazı engellemek için kurumsal sınıf PCIe 4.0 NVMe SSD sürücüler kullanılmalıdır. Özellikle rastgele 4K düşük kuyruk derinliğindeki (QD1) okuma/yazma performansı, cTrader loglarının diske yazılırken işlemciyi bekletmesini önler.
Disk I/O Performansının Doğrulanması (FIO Benchmark)
Sunucu üzerindeki NVMe diskin rastgele 4K gecikme ve IOPS değerleri fio ile test edilmelidir:
# FIO paketini yükle
apt-get install -y fio
# Doğrudan I/O (O_DIRECT) ile 4K rastgele okuma/yazma testi
fio --name=direct-io-test \
--filename=/tmp/fio_test_file \
--size=2G \
--rw=randrw \
--rwmixread=75 \
--bs=4k \
--ioengine=libaio \
--iodepth=1 \
--direct=1 \
--runtime=30 \
--time_based \
--group_reporting
Kurumsal standartlarda bir NVMe depolama biriminde QD1 rastgele gecikme değerinin (lat/clat) p99 seviyesinde 80 mikrosaniyenin altında ve okuma IOPS değerinin 50.000 IOPS üzerinde kalması gerekir.
NVMe Linux I/O Zamanlayıcı (Scheduler) Yapılandırması
Modern NVMe sürücüler kendi donanımsal çoklu kuyruk (multi-queue) sistemine sahiptir. Linux çekirdeğindeki eski kuyruk algoritmaları (mq-deadline veya bfq) işletim sistemi katmanında fazladan CPU yükü yaratır. NVMe cihazlar için zamanlayıcı none moduna getirilmelidir:
# NVMe cihazın zamanlayıcısını doğrudan donanıma bırak
echo none > /sys/block/nvme0n1/queue/scheduler
# Yeniden başlatmalarda kalıcı olması için Udev kuralı tanımla
cat << 'EOF' > /etc/udev/rules.d/60-nvme-scheduler.rules
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
EOF
udevadm control --reload-rules
udevadm trigger
Ayrıca dosya sistemi seviyesinde diske her erişimde dosya erişim zaman damgasının güncellenmesini engelleyerek disk I/O yükünü düşürmek için bağlama parametrelerine noatime,nodiratime eklenmelidir:
# /etc/fstab yapılandırma örneği
UUID=xxxx-xxxx-xxxx / ext4 defaults,noatime,nodiratime,commit=60 0 1
tropic.host platformunun KVM mimarisi, kurumsal sınıf PCIe 4.0 NVMe depolama üniteleriyle desteklenmiş olup, rastgele 4K QD1 işlemlerinde termal kısıtlama (thermal throttling) ve I/O kuyruk tıkanması olmaksızın sürekli yüksek veri aktarım hızını garanti eder. Bu donanımsal zemin; yüksek frekanslı cBot stratejilerinin ihtiyaç duyduğu sıfır steal time, yüksek tek çekirdek saat hızı ve düşük I/O gecikmesi gereksinimlerini eksiksiz karşılayarak emir iletim zincirini donanım seviyesinde koruma altına alır.
Windows Server VDS Üzerinde cTrader Kurulumu ve Uzak Masaüstü (RDP) Ayarları
Windows Server çekirdeği üzerinde barındırılan ctrader vds algoritmik ticaret altyapılarında, donanım katmanından işletim sistemi kullanıcı alanına (user-space) geçiş sürecinde en sık karşılaşılan kesinti kaynağı RDP (Remote Desktop Protocol) oturum yönetimi ve yetkisiz erişim denemeleridir. Spotware cTrader, grafiksel kullanıcı arayüzü (WPF / DirectX) ve arka plandaki .NET Core yürütme ortamına doğrudan bağımlı bir mimariye sahiptir. Bu nedenle platformun headless (servis tabanlı) bir daemon yerine izole bir masaüstü oturumu içinde kesintisiz çalışması, işletim sistemi yeniden başladığında otomatik olarak belleğe yüklenmesi ve uzaktan erişim portunun ağ tabanlı kaba kuvvet (brute-force) saldırılarına karşı tamamen izole edilmesi gerekir.
RDP Varsayılan Portunun Değiştirilmesi ve Windows Güvenlik Duvarı Yapılandırması
İnternete açık statik IPv4 adresine sahip sunucularda standart TCP 3389 portu, botnet ağları ve otomatik port tarayıcılar (masscan, zmap) tarafından saniyede binlerce yetkisiz oturum açma isteğiyle hedef alınır. Bu istekler lsass.exe sürecinde yoğun CPU kesintilerine (hardware interrupts / DPC) ve işlemci kuyruk derinliğinde dalgalanmalara yol açarak cBot emir iletim döngülerinde mikrosaniye düzeyinde gecikme (jitter) yaratır.
RDP dinleme portunu IANA dinamik/özel port bloğunda yer alan güvenli bir porta (örneğin TCP 54892) taşımak ve Windows Advanced Firewall kurallarını bu porta göre sıkılaştırmak için PowerShell konsolunda (Administrator yetkisiyle) aşağıdaki blok çalıştırılmalıdır:
# Hedef RDP port tanımı
$CustomRdpPort = 54892
# 1. Kayıt Defteri (Registry) üzerinde RDP dinleme portunu güncelle
$RdpRegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Set-ItemProperty -Path $RdpRegPath -Name "PortNumber" -Value $CustomRdpPort -Type DWord
# 2. Ağ Güvenlik Düzeyi Kimlik Doğrulamasını (NLA) zorunlu kıl
Set-ItemProperty -Path $RdpRegPath -Name "UserAuthentication" -Value 1 -Type DWord
# 3. Yeni port için gelişmiş güvenlik duvarı kuralı tanımla
New-NetFirewallRule -DisplayName "Custom RDP Port ($CustomRdpPort)" `
-Direction Inbound `
-LocalPort $CustomRdpPort `
-Protocol TCP `
-Action Allow `
-Profile Any `
-Description "Ozel RDP Portu - ctrader vds algoritmik ticaret yonetimi"
# 4. Varsayılan 3389 RDP kuralını devre dışı bırak
Disable-NetFirewallRule -DisplayGroup "Remote Desktop"
Disable-NetFirewallRule -Name "RemoteDesktop-UserMode-In-TCP"
# 5. TermService (Uzak Masaüstü Hizmeti) yeniden başlatılarak portu dinlemeye al
Restart-Service -Name TermService -Force
Eğer yönetim yaptığınız istemci IP adresi statik ise, güvenlik duvarı kuralını yalnızca ilgili IP bloğuna sınırlandırmak sıfırıncı gün (0-day) RDP zafiyetlerine karşı mutlak izolasyon sağlar:
Set-NetFirewallRule -DisplayName "Custom RDP Port ($CustomRdpPort)" -RemoteAddress "203.0.113.50/32"
Otomatik Oturum Açma (Autologon) ve Ekran Kilitleme Mimarisi
KVM tabanlı altyapılarda veya Windows Server güncellemeleri sonrasında makine yeniden başlatıldığında, bir kullanıcı oturum açana kadar cTrader.exe başlatılamaz. cTrader arka planda Windows Servisi (Windows Service) olarak çalışacak şekilde tasarlanmamıştır; emir döngülerini, grafik verilerini ve broker FIX API / WebSocket köprülerini yönetebilmek için aktif bir interaktif masaüstü oturumuna ihtiyaç duyar.
Sistemin yeniden başlatılmasının ardından trading kullanıcısının otomatik olarak oturum açmasını sağlamak ve oturum açıldığı anda konsolun fiziksel/VNC erişimine karşı kilitli kalmasını temin etmek için aşağıdaki adımlar uygulanmalıdır.
1. Kayıt Defteri ile Autologon Yapılandırması
Sysinternals Autologon.exe aracı kullanılabileceği gibi, doğrudan Windows kayıt defteri üzerinden Local Security Authority (LSA) doğrulaması tanımlanabilir:
$WinlogonPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
# Hedef ticaret kullanıcısı ve kimlik bilgileri
$TradingUser = "TraderAdmin"
$TradingDomain = $env:COMPUTERNAME
$TradingPassword = "GucluParolaBurayaYazilacak"
Set-ItemProperty -Path $WinlogonPath -Name "AutoAdminLogon" -Value "1" -Type String
Set-ItemProperty -Path $WinlogonPath -Name "DefaultUserName" -Value $TradingUser -Type String
Set-ItemProperty -Path $WinlogonPath -Name "DefaultDomainName" -Value $TradingDomain -Type String
Set-ItemProperty -Path $WinlogonPath -Name "DefaultPassword" -Value $TradingPassword -Type String
Set-ItemProperty -Path $WinlogonPath -Name "ForceAutoLogon" -Value "1" -Type String
2. Güvenlik: Oturum Açıldığı Anda İş İstasyonunun Kilitlenmesi
Autologon devreye girdiğinde masaüstü bellekte başlatılır ancak ekran yetkisiz gözlemcilere karşı korunmasız kalabilir. Bunu önlemek için Windows Task Scheduler üzerine oturum açma anında çalışan ve masaüstünü derhal kilitleyen bir görev enjekte edilir:
$Action = New-ScheduledTaskAction -Execute "rundll32.exe" -Argument "user32.dll,LockWorkStation"
$Trigger = New-ScheduledTaskTrigger -AtLogOn -User $TradingUser
$Principal = New-ScheduledTaskPrincipal -UserId $TradingUser -LogonType Interactive -RunLevel Highest
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -ExecutionTimeLimit (New-TimeSpan -Minutes 1)
Register-ScheduledTask -TaskName "LockSessionOnAutologon" `
-Action $Action `
-Trigger $Trigger `
-Principal $Principal `
-Settings $Settings `
-Description "Autologon sonrasi trading oturumunu aninda kilitler"
RDP Bağlantısı Kesildiğinde (Disconnect) cTrader Sürecinin Askıya Alınmasını Önleme
Kullanıcı RDP penceresini kapattığında (X butonuna basıldığında), Windows varsayılan grup ilkeleri oturumu "Disconnected" durumuna çeker. Bazı Windows Server sürümlerinde bu durum, GUI iş parçacıklarının (threads) GPU ve bellek tamponlarının (framebuffer) serbest bırakılmasına, DirectX bağlamının donmasına ve cBot'ların döngü sürelerinin uzamasına neden olur.
Oturumun arka planda tam render kapasitesiyle çalışmaya devam etmesi için Group Policy parametreleri doğrudan kayıt defterine yazılmalıdır:
$TsPoliciesPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
if (!(Test-Path $TsPoliciesPath)) { New-Item -Path $TsPoliciesPath -Force }
# RDP bağlantısı kesildiğinde oturumun sonlandırılmasını veya askıya alınmasını engelle
Set-ItemProperty -Path $TsPoliciesPath -Name "MaxDisconnectionTime" -Value 0 -Type DWord
Set-ItemProperty -Path $TsPoliciesPath -Name "MaxIdleTime" -Value 0 -Type DWord
Set-ItemProperty -Path $TsPoliciesPath -Name "ResetBroken" -Value 0 -Type DWord
# WDDM grafik sürücüsü yerine RDP XDDM geriye dönük tampon belleğini zorlayarak headless renderi koru
$WddmPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"
if (!(Test-Path $WddmPath)) { New-Item -Path $WddmPath -Force }
Set-ItemProperty -Path $TsPoliciesPath -Name "fEnableWddmDriver" -Value 0 -Type DWord
.NET Çalışma Zamanı Kurulumu ve cTrader Watchdog Servisi
cTrader güncel sürümleri bağımsız .NET Desktop Runtime paketine ihtiyaç duyar. Platformun ve cBot süreçlerinin çökme ihtimaline karşı bir PowerShell watchdog süreci oluşturularak Task Scheduler ile denetlenmelidir.
# 1. En güncel .NET Desktop Runtime paketini indir ve sessiz modda kur
$DotNetUrl = "https://download.visualstudio.microsoft.com/download/pr/dotnet-runtime-desktop-windows-x64.exe"
$InstallerPath = "$env:TEMP\dotnet-desktop-runtime.exe"
Invoke-WebRequest -Uri $DotNetUrl -OutFile $InstallerPath -UseBasicParsing
Start-Process -FilePath $InstallerPath -ArgumentList "/install /quiet /norestart" -Wait
Remove-Item -Path $InstallerPath -Force
# 2. cTrader Süreç İzleme ve Otomatik Kurtarma Scripti (Watchdog)
$WatchdogScript = @'
$ProcessName = "cTrader"
$cTraderPath = "C:\Users\TraderAdmin\AppData\Local\Spotware\cTrader\cTrader.exe"
while ($true) {
$Process = Get-Process -Name $ProcessName -ErrorAction SilentlyContinue
if (-not $Process) {
Write-Output "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') - cTrader calismiyor! Yeniden baslatiliyor..."
Start-Process -FilePath $cTraderPath
}
Start-Sleep -Seconds 15
}
'@
$WatchdogDir = "C:\TradingScripts"
if (!(Test-Path $WatchdogDir)) { New-Item -Path $WatchdogDir -ItemType Directory -Force }
$WatchdogScript | Out-File -FilePath "$WatchdogDir\cTrader-Watchdog.ps1" -Encoding utf8
# 3. Watchdog'u Oturum Açıldığında Başlatacak Zamanlanmış Görev Olarak Tanımla
$WatchAction = New-ScheduledTaskAction -Execute "powershell.exe" `
-Argument "-ExecutionPolicy Bypass -WindowStyle Hidden -File C:\TradingScripts\cTrader-Watchdog.ps1"
$WatchTrigger = New-ScheduledTaskTrigger -AtLogOn -User $TradingUser
$WatchPrincipal = New-ScheduledTaskPrincipal -UserId $TradingUser -LogonType Interactive -RunLevel Highest
$WatchSettings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit 0 -RestartCount 3 -RestartInterval (New-TimeSpan -Minutes 1)
Register-ScheduledTask -TaskName "cTraderWatchdog" `
-Action $WatchAction `
-Trigger $WatchTrigger `
-Principal $WatchPrincipal `
-Settings $WatchSettings -Force
Windows Ağ Yığını (TCP/IP) ve Nagle Algoritması Optimizasyonu
Yüksek frekanslı algoritmik emir iletiminde Windows varsayılan TCP parametreleri küçük paketleri (örneğin 64–128 byte boyutundaki piyasa verisi onayları ve FIX mesajları) arabelleğe alarak birleştirmeye çalışır (Nagle algoritması). Bu durum emir iletim süresine 10 ila 40 milisaniyelik yapay ağ gecikmesi ekler.
cTrader'ın broker köprüsüyle kurduğu soket iletişiminde gecikmeyi asgariye indirmek için Nagle algoritması devre dışı bırakılmalı ve TCP ACK frekansı bire indirilmelidir:
# Ağ bağdaştırıcı GUID listesini çek
$Interfaces = Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces"
foreach ($Interface in $Interfaces) {
$Path = $Interface.PSPath
# Nagle algoritmasını devre dışı bırak (TCP_NODELAY)
Set-ItemProperty -Path $Path -Name "TcpNoDelay" -Value 1 -Type DWord
# Her TCP paketine anında ACK yanıtı ver (Gecikmeli ACK mekanizmasını kapat)
Set-ItemProperty -Path $Path -Name "TcpAckFrequency" -Value 1 -Type DWord
Set-ItemProperty -Path $Path -Name "TcpDelAckTicks" -Value 0 -Type DWord
}
# Windows TCP global yığın parametrelerini optimize et
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global rss=enabled
netsh int tcp set global chimney=disabled
netsh int tcp set global dca=enabled
netsh int tcp set global netdma=enabled
tropic.host bulut altyapısında sunulan saf KVM mimarisi, sıfır işlemci paylaştırımı (%st = 0.0%) ve yüksek tek çekirdek saat frekansına sahip AMD EPYC işlemcileriyle bu yazılımsal optimizasyonların donanım seviyesinde tam verimle çalışmasını mümkün kılar. Frankfurt (Equinix FR2), Londra (LD4) ve İstanbul veri merkezlerine doğrudan BGP peering bağlantısı ve 1–10 Gbps hat kapasitesi sayesinde, ctrader vds algoritmik ticaret botlarınızın emir paketleri hem Windows ağ yığınında gecikmeye uğramadan hem de taşıyıcı seviyesinde en düşük ping rotası üzerinden doğrudan likidite havuzlarına ulaştırılır.
cBot Stratejilerinin 7/24 Kesintisiz Çalışması İçin Windows Servis Ayarları
Ağ gecikmelerinin mikrosaniye düzeyine çekilmesinin ardından operasyonel riskin merkez üssü, Windows NT çekirdeğinin süreç yönetimi ve varsayılan işletim sistemi servislerinin agresif arka plan politikalarıdır. Varsayılan yapılandırmayla çalışan bir Windows Server işletim sistemi; otomatik yama yüklemeleri sonrası zorunlu yeniden başlatmalar, agresif bellek sıkıştırma (Memory Compression), güç tasarrufu amaçlı çekirdek park etme (Core Parking) ve kullanıcı oturumu kapandığında arka plan süreçlerini askıya alan oturum izolasyonu nedeniyle algoritmik ticaret için doğrudan kesinti kaynağıdır.
Açık pozisyonların yönetildiği, bekleyen emirlerin milisaniyelik piyasa derinliğinde izlendiği bir senaryoda; terminalin bir saniye bile kontrol dışı kapanması kabul edilemez. Bu nedenle, Windows ortamının deterministik ve kesintisiz çalışan bir yürütme platformuna dönüştürülmesi gerekir.
1. Windows Update ve Zorunlu Yeniden Başlatma Döngülerinin Engellenmesi
Windows Update Orchestrator (UsoSvc) ve Windows Update (wuauserv) servisleri, güvenlik güncelleştirmeleri indirildiğinde sistemi önceden belirlenmiş bir bakım penceresinde yeniden başlatmaya zorlar. ctrader vds algoritmik ticaret altyapılarında bu durumun önüne geçmek için hem Local Group Policy hem de kayıt defteri (Registry) seviyesinde zorunlu kısıtlamalar uygulanmalı, ilgili zamanlanmış görevler (Scheduled Tasks) devre dışı bırakılmalıdır:
# Windows Update kayıt defteri anahtarlarını yapılandır
$WuPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$AuPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
if (!(Test-Path $WuPath)) { New-Item -Path $WuPath -Force | Out-Null }
if (!(Test-Path $AuPath)) { New-Item -Path $AuPath -Force | Out-Null }
# Otomatik güncellemeleri manuel onaya bağla (2: İndirmeden ve kurmadan önce bildir)
Set-ItemProperty -Path $AuPath -Name "NoAutoUpdate" -Value 0 -Type DWord
Set-ItemProperty -Path $AuPath -Name "AUOptions" -Value 2 -Type DWord
# Aktif kullanıcı oturumu varken zorunlu yeniden başlatmayı kesin olarak engelle
Set-ItemProperty -Path $AuPath -Name "NoAutoRebootWithLoggedOnUsers" -Value 1 -Type DWord
Set-ItemProperty -Path $AuPath -Name "AlwaysAutoRebootAtScheduledTime" -Value 0 -Type DWord
# Windows Update arka plan servislerini durdur ve başlangıç tipini devre dışı bırak
Stop-Service -Name "wuauserv", "UsoSvc" -Force -ErrorAction SilentlyContinue
Set-Service -Name "wuauserv" -StartupType Disabled
Set-Service -Name "UsoSvc" -StartupType Disabled
# Update Orchestrator yeniden başlatma görevlerini kilitle
$Tasks = @(
"\Microsoft\Windows\UpdateOrchestrator\Reboot",
"\Microsoft\Windows\UpdateOrchestrator\Reboot_AC",
"\Microsoft\Windows\UpdateOrchestrator\Schedule Scan",
"\Microsoft\Windows\WindowsUpdate\Scheduled Start"
)
foreach ($Task in $Tasks) {
Disable-ScheduledTask -TaskPath ($Task.Substring(0, $Task.LastIndexOf('\') + 1)) -TaskName ($Task.Substring($Task.LastIndexOf('\') + 1)) -ErrorAction SilentlyContinue
}
Bu yapılandırma sonrasında işletim sistemi, yönetici manuel olarak onay verip süreci tetiklemediği müddetçe hiçbir yama paketini otomatik olarak indirip sunucuyu yeniden başlatamaz.
2. Güç Planı, Uyku Modları ve Çekirdek Park Etmenin Devre Dışı Bırakılması
Algoritmik emir yürütmede anlık işlem gücü gereksinimi doğduğunda, işlemcinin düşük güç durumlarından (C-States / C1E, C6) tam frekans moduna (P0 State) geçmesi sırasında onlarca mikrosaniyelik donanımsal gecikme (jitter) meydana gelir. Maksimum performans planına geçilmeli, hazırda bekletme (hibernation) kapatılmalı ve disk zaman aşımları sıfırlanmalıdır:
:: Hazırda bekletme modunu kapat (hiberfil.sys dosyasını kaldırarak disk alanı da açar)
powercfg -h off
:: Yüksek Performans (High Performance) GUID şemasını etkinleştir
powercfg /setactive 8c5e7fda-e83b-4106-a1a9-3170d007746c
:: AC ve DC güç modlarında sabit disk uyku süresini sıfıra indir (Asla kapatma)
powercfg /change disk-timeout-ac 0
powercfg /change disk-timeout-dc 0
:: Monitör ve bekleme (standby) zaman aşımlarını kapat
powercfg /change monitor-timeout-ac 0
powercfg /change standby-timeout-ac 0
:: İşlemci çekirdek park etme (Core Parking) özelliğini devre dışı bırak (%100 minimum işlemci durumu)
powercfg /setacvalueindex scheme_current sub_processor PROCTHROTTLEMIN 100
powercfg /setacvalueindex scheme_current sub_processor CPMINCORES 100
powercfg /setactive scheme_current
3. Session 0 İzolasyon Sorunu ve Headless Grafik Oturumu Yönetimi
cTrader Desktop mimarisi, cBot stratejilerini yürütürken grafik arayüz motoruyla (WPF ve DirectX katmanı) doğrudan bağlantılı çalışır. Windows NT mimarisinde arka plan Windows Servisleri (services.exe), kullanıcı oturumlarından izole edilmiş olan Session 0 alanında çalıştırılır. Bir uygulamayı doğrudan standart Windows Servisi olarak çalıştırmak, Session 0 İzolasyonu nedeniyle GUI bağlamının başlatılamamasına, WPF grafik kütüphanelerinin çökmesine ve cBot'un sessizce sonlanmasına yol açar.
Bu mimari kısıtı aşmak ve sunucu her yeniden başladığında cTrader'ın tam interaktif oturumda (Session 1) otomatik olarak ayağa kalkmasını sağlamak için iki aşamalı bir mimari uygulanır: 1. Kayıt defteri tabanlı Windows AutoLogon mekanizması. 2. Uzak Masaüstü (RDP) oturumu kapatıldığında grafik oturumunun konsola devredilmesini (tscon) sağlayan bağlantı kesme mekanizması.
RDP oturumunu kapattığınızda grafik bağlamının donanım seviyesinde kilitlenmesini önlemek için sunucu masaüstüne Disconnect-RDP.bat betiği yerleştirilmelidir:
:: RDP oturumunu masaüstü grafik motorunu yok etmeden yerel konsola yönlendirerek kapat
for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (
%windir%\System32\tscon.exe %%s /dest:console
)
Bu script çalıştırıldığında RDP oturumu sonlanır; ancak Windows oturumu açık kalmaya ve DirectX grafik bağlamını arka planda render etmeye devam eder. Böylece cTrader grafikleri ve göstergeleri kesintisiz hesaplanır.
4. Gelişmiş PowerShell Süreç İzleme ve Watchdog Servisi
cBot'ların bellek sızıntıları (memory leak), kütüphane kilitlenmeleri (deadlock) veya istisnai durumlarda çökmesi riskine karşı sistemi 7/24 denetleyen, donma durumunu (Responding = False) tespit eden ve süreci anında kurtaran bir PowerShell Watchdog mekanizması kurulmalıdır.
Aşağıdaki script, C:\cBotScripts\cTraderWatchdog.ps1 dizinine yerleştirilir:
# cTrader Süreç Takip ve Kurtarma Watchdog Betiği
param (
[string]$ProcessPath = "C:\Users\Administrator\AppData\Local\Spotware\cTrader\cTrader.exe",
[string]$ProcessName = "cTrader",
[int]$MemoryLimitMB = 4096,
[int]$CheckIntervalSec = 15,
[string]$LogFile = "C:\cBotScripts\watchdog_runtime.log"
)
function Write-Log {
param ([string]$Message)
$TimeStamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss.fff"
"[$TimeStamp] $Message" | Out-File -FilePath $LogFile -Append -Encoding utf8
}
Write-Log "Watchdog servisi aktif edildi. Hedef: $ProcessName"
while ($true) {
try {
$Instances = Get-Process -Name $ProcessName -ErrorAction SilentlyContinue
if (!$Instances) {
Write-Log "UYARI: $ProcessName çalışmıyor. Süreç başlatılıyor..."
Start-Process -FilePath $ProcessPath
Start-Sleep -Seconds 10
continue
}
foreach ($Proc in $Instances) {
# Yanıt vermeyen (donmuş) süreç kontrolü
if (!$Proc.Responding) {
Write-Log "KRITIK: PID $($Proc.Id) yanıt vermiyor (Responding=False). Zorla sonlandırılıyor..."
Stop-Process -Id $Proc.Id -Force
Start-Sleep -Seconds 3
Start-Process -FilePath $ProcessPath
break
}
# Bellek tüketim sınırı kontrolü (Memory leak koruması)
$WorkingSetMB = [math]::Round($Proc.WorkingSet64 / 1MB, 2)
if ($WorkingSetMB -gt $MemoryLimitMB) {
Write-Log "UYARI: PID $($Proc.Id) bellek sınırını aştı ($WorkingSetMB MB > $MemoryLimitMB MB). Yeniden başlatılıyor..."
$Proc.CloseMainWindow() | Out-Null
Start-Sleep -Seconds 5
if (!$Proc.HasExited) { Stop-Process -Id $Proc.Id -Force }
Start-Process -FilePath $ProcessPath
break
}
}
}
catch {
Write-Log "HATA: Watchdog döngüsünde istisna oluştu: $_"
}
Start-Sleep -Seconds $CheckIntervalSec
}
Bu denetleyiciyi arka planda kalıcı bir servis olarak çalıştırmak için NSSM (Non-Sucking Service Manager) kullanılır:
:: NSSM ile Watchdog'u Windows Servisi olarak sisteme kaydet
nssm.exe install cBotWatchdog "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-ExecutionPolicy Bypass -NoProfile -File C:\cBotScripts\cTraderWatchdog.ps1"
nssm.exe set cBotWatchdog AppDirectory "C:\cBotScripts"
nssm.exe set cBotWatchdog Description "cTrader cBot 7/24 Execution Watchdog"
nssm.exe set cBotWatchdog Start SERVICE_AUTO_START
nssm.exe set cBotWatchdog AppRestartDelay 5000
:: Servisi başlat
net start cBotWatchdog
5. Windows Hata Bildirimi (WER) ve Çökme İletişim Kutularının Engellenmesi
Bir cBot beklenmedik bir bellek ihlali (AccessViolationException) veya yönetilmeyen C++ kütüphanesi çökmesi yaşadığında, Windows varsayılan olarak ekranda WerFault.exe aracılığıyla bir hata penceresi açar. Bu pencere kullanıcı tarafından "Kapat" butonuna tıklanana kadar sürecin RAM üzerinde askıda (zombie state) kalmasına neden olur. Bu durum, yukarıda kurduğumuz Watchdog mekanizmasının sürecin kapandığını algılamasını engeller.
Sistemin hata pencerelerini beklemeden süreci anında düşürmesi ve hata dökümünü (Crash Dump) diske yazması için Windows Error Reporting (WER) parametreleri optimize edilmelidir:
$WerPath = "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting"
# Hata iletişim kutularını bastır (UI gösterme)
Set-ItemProperty -Path $WerPath -Name "DontShowUI" -Value 1 -Type DWord
Set-ItemProperty -Path $WerPath -Name "Disabled" -Value 0 -Type DWord
# Otomatik çökme dökümü (Crash Dump) kayıt dizinini belirle
$DumpPath = "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\cTrader.exe"
if (!(Test-Path $DumpPath)) { New-Item -Path $DumpPath -Force | Out-Null }
# 1: Mini dump, 2: Full dump (Derinlemesine stack trace analizi için Mini Dump yeterlidir)
Set-ItemProperty -Path $DumpPath -Name "DumpType" -Value 1 -Type DWord
Set-ItemProperty -Path $DumpPath -Name "DumpCount" -Value 5 -Type DWord
Set-ItemProperty -Path $DumpPath -Name "DumpFolder" -Value "C:\cBotLogs\CrashDumps" -Type ExpandString
Altyapı Kararlılığı ve Donanım Uyumu
Tüm bu işletim sistemi optimizasyonları ve watchdog mekanizmaları, alttaki sanallaştırma katmanının kararlılığı oranında güvenilirdir. Tipik aşırı satımlı (oversold) VPS ortamlarında başka bir kiracının yüksek disk veya işlemci kullanımı nedeniyle sanal sunucunuza CPU Steal Time yansıdığında (%st > %5.0), Watchdog süreci sahte bir kilitlenme algılayarak cTrader'ı gereksiz yere yeniden başlatabilir.
tropic.host platformundaki saf KVM mimarisinde %st = 0.0% değeri donanımsal olarak garanti edilir. Bu sayede watchdog döngüleri milisaniyelik hassasiyetle çalışır; yanlış alarmlar tamamen bertaraf edilir. Ayrıca PCIe 4.0 NVMe altyapısının sağladığı 50.000+ IOPS (4K QD1 rastgele okuma/yazma) kapasitesi, cBot stratejilerinin saniyede binlerce tick verisini ve yürütme günlüğünü diske yazarken işletim sistemi genelinde I/O kuyruk gecikmesi (Queue Depth) yaşanmasının önüne geçer. Böylece ctrader vds algoritmik ticaret operasyonlarınız, harici bir insan müdahalesine gerek kalmaksızın 7/24 deterministik bir kararlılıkla sürdürülür.
Ağ Kesintilerine Karşı Yedekleme ve Acil Kurtarma Planı (Disaster Recovery)
Algoritmik işlem operasyonlarında sermaye kaybına yol açan en kritik senaryolar, yazılım mantık hatalarından ziyade altyapı seviyesindeki network kopmaları, transit omurga (Tier-1) BGP rota kararsızlıkları ve işletim sistemi çökmeleridir. Bir cBot mikro ölçekte yüzlerce emir üretirken sanal sunucunun dış dünya ile bağlantısının kesilmesi, açıkta kalan pozisyonların stop-loss (SL) seviyelerinin broker sunucusuna iletilememesine ya da sunucu taraflı trailing-stop mekanizmalarının işletilememesine neden olabilir. Bu riskleri bertaraf etmek adına ctrader vds algoritmik ticaret altyapısında çift katmanlı bir acil kurtarma planı (Disaster Recovery - DR) ve milisaniyelik telemetri mekanizması yapılandırılmalıdır.
Strateji Dosyaları, Set Parametreleri ve Durum Veritabanlarının Otomasyonu
cTrader platformunda çalışan cBot'lar kaynak kod (.cs), derlenmiş paket (.algo), optimize edilmiş parametre setleri (.cbotset) ve çalışma zamanı durum verilerinden (SQLite veya yerel JSON dosyaları) oluşur. İşletim sistemi çökmesi durumunda sıfırdan kurulum süresini (Recovery Time Objective - RTO) sıfıra indirmek ve veri kaybını (Recovery Point Objective - RPO) engellemek için bu dizinler harici, şifrelenmiş bir nesne depolama (S3) veya Git deposuna periyodik olarak senkronize edilmelidir.
cTrader'ın kritik çalışma dizinleri şunlardır: * Kaynak Kodlar ve Algolar: C:\Users\<Kullanıcı>\Documents\cTrader\Sources\Robots * Kullanıcı Set Dosyaları: C:\Users\<Kullanıcı>\Documents\cTrader\Sources\Robots\*\*.cbotset * Bot Durum Veritabanları (Stateful Storage): cBot içerisinde kullanılan özel DataStore veya %LOCALAPPDATA%\Spotware\... altındaki uygulama profilleri.
Aşağıdaki PowerShell betiği, strateji dosyalarını ve çalışma parametrelerini yerel bir Git deposunda sürümleyerek değişiklikleri hash bazında denetler, ardından AES-256 ile şifreleyerek uzak bir S3 havuzuna yedekler:
# Sync-TradingState.ps1 - cTrader DR Yedekleme Motoru
param (
[string]$BackupSource = "$env:USERPROFILE\Documents\cTrader\Sources\Robots",
[string]$ArchiveDest = "C:\cBotBackups\Snapshots",
[string]$S3Remote = "s3-backup:trading-dr-vault/cTrader",
[string]$EncryptionPass = "GucluParola_Hex9823#!"
)
$ErrorActionPreference = "Stop"
$TimeStamp = Get-Date -Format "yyyyMMdd_HHmmss"
$SnapshotZip = "$ArchiveDest\cTrader_State_$TimeStamp.zip"
$EncryptedFile = "$SnapshotZip.aes"
# Dizin denetimi
if (!(Test-Path $ArchiveDest)) {
New-Item -Path $ArchiveDest -ItemType Directory -Force | Out-Null
}
# 1. Kaynak dizin hash kontrolü (Değişiklik yoksa boşuna I/O üretme)
$CurrentHash = (Get-ChildItem -Path $BackupSource -Recurse -File |
Get-FileHash -Algorithm SHA256 |
Select-Object -ExpandProperty Hash) -join "" |
Get-FileHash -Algorithm SHA256 |
Select-Object -ExpandProperty Hash
$LastHashFile = "$ArchiveDest\last_state.hash"
if (Test-Path $LastHashFile) {
$PreviousHash = Get-Content $LastHashFile
if ($CurrentHash -eq $PreviousHash) {
Write-Output "[$TimeStamp] Strateji dosyalarında değişiklik yok. Senkronizasyon atlandı."
exit 0
}
}
# 2. State Snapshot oluştur
Write-Output "[$TimeStamp] Değişiklik algılandı. Arşivleniyor..."
Compress-Archive -Path $BackupSource -DestinationPath $SnapshotZip -Force
# 3. 7-Zip ile AES-256 Şifreleme (Bellek içi borulama veya geçici dosya)
& "C:\Program Files\7-Zip\7z.exe" a -tzip -p"$EncryptionPass" -mem=AES256 "$EncryptedFile" "$SnapshotZip" | Out-Null
Remove-Item -Path $SnapshotZip -Force
# 4. Rclone ile şifreli arşivi harici nesne depolama (S3) alanına replike et
& rclone copyto "$EncryptedFile" "$S3Remote/cTrader_State_$TimeStamp.zip.aes" --fast-list --retries 3
# 5. Başarılı senkronizasyon sonrası hash güncelle ve eski arşivleri temizle (7 günlük rotasyon)
Set-Content -Path $LastHashFile -Value $CurrentHash
Remove-Item -Path $EncryptedFile -Force
Get-ChildItem -Path $ArchiveDest -Filter "*.aes" |
Where-Object { $_.CreationTime -lt (Get-Date).AddDays(-7) } |
Remove-Item -Force
Write-Output "[$TimeStamp] DR snapshot başarıyla uzak depolamaya aktarıldı."
Bu otomasyonu Windows Görev Zamanlayıcı'ya (Task Scheduler) yüksek öncelikli ve I/O kuyruğunu kilitlemeyecek şekilde bağlamak için:
$Action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NonInteractive -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\Sync-TradingState.ps1'
$Trigger = New-ScheduledTaskTrigger -Daily -At 00:05
$Settings = New-ScheduledTaskSettingsSet -MultipleInstances IgnoreNew -Priority 7
Register-ScheduledTask -Action $Action -Trigger $Trigger -TaskName "cTrader_DR_StateSync" -Description "Strateji durum yedeği" -Settings $Settings -User "NT AUTHORITY\SYSTEM"
Anlık Durum Telemetrisi ve Çok Kanallı Alarm Mekanizması (Heartbeat & Webhook)
İşlem stratejinizin durumundan haberdar olmak için yalnızca logları izlemek yetersizdir. Sunucunun ağ gecikmesi (TCP RTT), cTrader işlemcisi üzerindeki iş parçacığı (thread) kilitlenmeleri ve aracı kurum gateway soketinin erişilebilirliği gerçek zamanlı izlenmelidir.
Aşağıdaki mimaride bağımsız bir PowerShell arka plan servisi (Daemon), aracı kurumun FIX/cTID sunucu portlarına her 15 saniyede bir SYN paketi göndererek RTT değerini ölçer; cTrader sürecinin bellek tüketimini analiz eder ve anormal bir durumda Telegram Webhook API üzerinden anlık uyarı fırlatır:
# Watchdog-Telemetry.ps1 - Telemetri ve Anlık Bildirim Ajanı
$TelegramBotToken = "7123456789:AAFxExampleTokenGoesHere"
$TelegramChatID = "-1001234567890"
$BrokerHost = "live-gateway.ctrader.com"
$BrokerPort = 5212 # cTrader Open API / FIX SSL portu
$MaxLatencyMs = 45
$MaxConsecutiveDrops = 3
$FailureCount = 0
function Send-TelegramAlert {
param ([string]$Message)
$Uri = "https://api.telegram.org/bot$TelegramBotToken/sendMessage"
$Body = @{
chat_id = $TelegramChatID
text = $Message
parse_mode = "Markdown"
} | ConvertTo-Json -Compress
try {
Invoke-RestMethod -Uri $Uri -Method Post -Body $Body -ContentType 'application/json' -TimeoutSec 5 | Out-Null
} catch {
Write-Error "Telegram API iletisim hatasi: $_"
}
}
while ($true) {
$Now = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
# 1. cTrader Process Durumu
$Proc = Get-Process -Name "cTrader" -ErrorAction SilentlyContinue
if (!$Proc) {
Send-TelegramAlert "🚨 *KRİTİK HATA:* cTrader süreci sonlandı! Sunucu: `$env:COMPUTERNAME` | Zaman: `$Now`"
Start-Sleep -Seconds 60
continue
}
# 2. Broker Gateway TCP Soket ve RTT Testi
$Stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
$TcpClient = New-Object System.Net.Sockets.TcpClient
$ConnectTask = $TcpClient.ConnectAsync($BrokerHost, $BrokerPort)
$Timeout = [Threading.Tasks.Task]::Delay(2000)
$Completed = [Threading.Tasks.Task]::WhenAny($ConnectTask, $Timeout).Result
$Stopwatch.Stop()
$Latency = $Stopwatch.ElapsedMilliseconds
if ($Completed -eq $ConnectTask -and $TcpClient.Connected) {
$TcpClient.Close()
$TcpClient.Dispose()
# Gecikme sapması (Jitter) denetimi
if ($Latency -gt $MaxLatencyMs) {
Send-TelegramAlert "⚠️ *YÜKSEK GECİKME:* Broker Gateway RTT `$Latency ms` (> $MaxLatencyMs ms eşiği aşıldı). Slippage riski!"
}
$FailureCount = 0
} else {
if ($TcpClient.Connected) { $TcpClient.Close() }
$FailureCount++
Write-Warning "Broker baglanti testi basarisiz ($FailureCount/$MaxConsecutiveDrops)"
if ($FailureCount -ge $MaxConsecutiveDrops) {
Send-TelegramAlert "🚨 *AĞ KESİNTİSİ:* Broker sunucusuna (`$BrokerHost:$BrokerPort`) $FailureCount ardışık denemede ulaşılamadı! Acil durum planını devreye alın."
# Kritik durumda yerel acil durum komut dosyasını tetikle
& "C:\Scripts\Emergency-CircuitBreaker.ps1"
$FailureCount = 0
}
}
Start-Sleep -Seconds 15
}
Bölünmüş Beyin (Split-Brain) Önleme ve Otomatik Devralma (Failover) Mimarisi
Finansal piyasalarda iki sunucunun aynı anda aynı ticaret hesabına emir göndermesi (Split-Brain senaryosu), çift pozisyon açılmasına, teminatın (margin) saniyeler içinde tükenmesine ve hesabın stop-out olmasına yol açar. Bu sebeple sıcak yedek (Hot-Standby) sunucular pasif modda beklemeli ve bir dağıtık kilit (Distributed Mutex) üzerinden yönetilmelidir.
Failover mekanizması şu kurallara dayanmalıdır:
+-------------------------------------------------------------+
| Ana Sunucu (Primary Node) |
| - cBot Aktif |
| - Her 5 saniyede bir S3/KV havuzuna kilit uzatması (Lease) |
+------------------------------+------------------------------+
|
Heartbeat Kesintisi (> 30s)
|
v
+-------------------------------------------------------------+
| İkincil Sunucu (Cold/Warm Standby) |
| - Kilidi Devralır (Lease Acquisition) |
| - Broker Open API üzerinden açık pozisyonları sorgular |
| - State tutarlılığını onaylar ve cTrader'ı tetikler |
+-------------------------------------------------------------+
- Lease (Kira) Bazlı Kilit: Birincil VDS, harici bir Redis veya S3 nesnesine her 5 saniyede bir Unix Timestamp damgası bırakır.
- Kira Aşımı: İkincil sunucu bu damgayı izler. Eğer son güncelleme zamanı
30 saniyeboyunca yenilenmediyse, birincil sunucunun kilitlendiğine veya ağının tamamen koptuğuna karar verir. - Zorunlu İzolasyon (STONITH): İkincil sunucu stratejiyi ayağa kaldırmadan önce, birincil sunucunun olası yarı-çökme durumunda emir iletmesini engellemek için broker API üzerinden ilgili alt-hesabın oturum anahtarını (OAuth access token) geçersiz kılar veya yeni oturum açarak önceki soketi düşürür.
Ağ Katmanı Stabilitesi ve Altyapı Standartları
Uygulama katmanında kurulan en sofistike Disaster Recovery senaryoları bile, altta çalışan hipervizörün I/O gecikmeleri veya dengesiz ağ anahtarlama donanımları karşısında çaresiz kalabilir. ctrader vds algoritmik ticaret operasyonunun başarısı, doğrudan sunucunun ağ arayüz kartına (vNIC) tahsis edilen gecikme profiline ve sanallaştırma mimarisine bağlıdır.
Geleneksel aşırı satımlı (oversold) VPS sağlayıcılarında meydana gelen gürültülü komşu (noisy neighbor) etkisi, TCP paketlerinin soket arabelleğinde (socket buffer) sıraya girmesine ve milisaniyelik mikro-kesintilere yol açar. Bu kesintiler Watchdog servislerinin yanlış tetiklenmesine neden olarak algoritmanın en likit piyasa anlarında devre dışı kalmasıyla sonuçlanır.
tropic.host bulut altyapısında sunulan saf KVM mimarisinde %st = 0.0% değeri donanımsal olarak izole edildiğinden, telemetri ajanları ve soket yoklamaları hiçbir zaman işletim sistemi zamanlayıcı (CPU scheduler) gecikmesine takılmaz. Frankfurt (Equinix FR2), Londra (LD4), Amsterdam ve İstanbul gibi finansal veri merkezlerinin yoğunlaştığı kritik internet değişim noktalarına (IXP) doğrudan BGP peering bağlantısı sağlayan 1–10 Gbps yedekli omurga, paket kaybı (packet loss) oranını %0.0 düzeyinde tutar. Bu sayede broker ağ geçitlerine yönelik p99 gecikme dalgalanmaları bertaraf edilir; kurulan acil durum ve yedekleme döngüleri, gerçek bir felaket anı haricinde asılsız alarmlar üretmeden deterministik biçimde yürütülür.
Sıkça Sorulan Sorular (SSS)
cTrader cBot çalıştırmak için VDS sunucuda ne kadar gecikme (ping) hedeflenmelidir?
Forex ve CFD piyasalarında emir kaymasını (slippage) önlemek için likidite sağlayıcıların bulunduğu Londra (LD4) veya Frankfurt sunucularına 1–3 ms gecikme hedeflenmelidir.
Neden cTrader için paylaşımlı sunucu yerine KVM VDS tercih edilmelidir?
KVM sanallaştırma, %st=0.0% CPU Steal Time garantisi verir. Paylaşımlı sunucularda komşu kullanıcıların işlemciyi meşgul etmesi, emirlerin gecikmeli iletilmesine neden olur.