Shard Allocation Derinlemesine — Awareness ve Kurallar

Giriş — Elasticsearch'ün "Emlak Komisyoncusu"

Bir şehirdeki emlak komisyoncusunu düşün. Binlerce daireyi (shard), yüzlerce binaya (node) dağıtması gerekiyor. Ama rastgele dağıtamaz: aynı dairenin kopyası aynı binada olmamalı (bina çökerse ikisi de gider), deprem bölgesindeki binalara dikkatli yerleştirmeli, bir bina doluysa oraya daire koymamalı, tadilattaki binalardan daireleri taşımalı. Üstelik binalar sürekli ekleniyor, çıkarılıyor, dolup boşalıyor.

Elasticsearch'ün shard allocation mekanizması tam olarak bu iş. Master node, "allocation decider" adlı bir karar mekanizmasıyla her shard'ı en uygun node'a yerleştirir. Bu derste bu mekanizmanın her detayını, her ayarını, her edge case'ini göreceğiz.

1. Allocation Mekanizmasının Temelleri

Allocation Nasıl Çalışır?

Master node, cluster state her değiştiğinde allocation kararlarını yeniden değerlendirir:

Cluster State Değişikliği
        ↓
Master Node: "Hangi shard'lar unassigned?"
        ↓
Allocation Deciders (karar ziniri)
├── SameShardAllocationDecider → Primary ve replica aynı node'da olamaz
├── FilterAllocationDecider → include/exclude/require kuralları
├── DiskThresholdDecider → Disk watermark kontrolü
├── AwarenessAllocationDecider → Zone/rack farkındalığı
├── ShardsLimitAllocationDecider → Node başına shard limiti
├── ReplicaAfterPrimaryActiveDecider → Önce primary, sonra replica
└── ...20+ decider daha
        ↓
En uygun node seçilir → Shard atanır

Allocation Durumlarını Anlama

GET _cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason

# Shard durumları:
# STARTED     → Shard aktif, node üzerinde çalışıyor
# INITIALIZING → Shard başlatılıyor (recovery devam ediyor)
# RELOCATING  → Shard başka node'a taşınıyor
# UNASSIGNED  → Shard hiçbir node'a atanamadı (SORUN!)

UNASSIGNED Shard Nedenleri:

2. Allocation Awareness — Rack/Zone/Region Farkındalığı

Awareness Nedir?

Allocation awareness, Elasticsearch'e fiziksel altyapınızın topolojisini öğretir. Böylece shard'ları rack'lere, availability zone'lara veya region'lara göre akıllıca dağıtır.

Awareness olmadan:

Node-1 (Zone A): [shard-0-pri] [shard-0-rep]  ← İkisi de aynı zone!
Node-2 (Zone B): boş

Zone A çökerse → VERİ KAYBI!

Awareness ile:

Node-1 (Zone A): [shard-0-pri]
Node-2 (Zone B): [shard-0-rep]  ← Farklı zone'larda

Zone A çökerse → Replica'dan devam!

Awareness Konfigürasyonu

# elasticsearch.yml — Her node'da

# Node-1 (Zone A)
node.attr.zone: zone-a
node.attr.rack: rack-1

# Node-2 (Zone B)
node.attr.zone: zone-b
node.attr.rack: rack-2

// Cluster ayarlarında awareness tanımla
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone"
  }
}

Bu ayar sonrasında Elasticsearch, primary ve replica shard'ları farklı zone'lara yerleştirmeye çalışır. "Çalışır" diyorum çünkü bu soft rule — eğer başka zone yoksa, aynı zone'a da koyar.

Multi-Level Awareness

Birden fazla attribute ile awareness tanımlayabilirsiniz:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone,rack"
  }
}

Bu durumda ES önce zone'a göre, sonra rack'a göre dağıtır:

Zone A
├── Rack 1: [shard-0-pri]
└── Rack 2: [shard-1-pri]

Zone B
├── Rack 3: [shard-0-rep]
└── Rack 4: [shard-1-rep]

Node Attribute'larını Kontrol Etme

# Tüm node'ların attribute'larını gör
GET _cat/nodeattrs?v&h=node,attr,value

# Çıktı:
# node     attr  value
# node-1   zone  zone-a
# node-1   rack  rack-1
# node-2   zone  zone-b
# node-2   rack  rack-2
# node-3   zone  zone-a
# node-3   rack  rack-3

3. Forced Awareness — Katı Zone Dağıtımı

Forced Awareness Nedir?

Normal awareness "best effort" — zone yoksa aynı zone'a koyar. Forced awareness ise katıdır: tanımlanan tüm zone'lar mevcut değilse, replica'ları UNASSIGNED bırakır.

Bu neden önemli? Diyelim ki 3 zone'unuz var ama Zone C'deki tüm node'lar düştü. Normal awareness, Zone C'ye gitmesi gereken replica'ları Zone A ve B'ye koyar. Zone A da düşerse — veri kaybı!

Forced awareness ile Zone C'ye gitmesi gereken replica'lar UNASSIGNED kalır. Cluster yellow olur ama veri kaybı riski azalır.

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone",
    "cluster.routing.allocation.awareness.force.zone.values": "zone-a,zone-b,zone-c"
  }
}

Senaryo: 2 Zone, 1 Replica

// 2 zone, forced awareness
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone",
    "cluster.routing.allocation.awareness.force.zone.values": "zone-a,zone-b"
  }
}

// Index: 2 primary, 1 replica = 4 shard
PUT my-index
{
  "settings": {
    "number_of_shards": 2,
    "number_of_replicas": 1
  }
}

// Dağılım:
// Zone A: [shard-0-pri] [shard-1-pri]
// Zone B: [shard-0-rep] [shard-1-rep]
//
// Zone B çökerse:
// Zone A: [shard-0-pri] [shard-1-pri]
// Replica'lar: UNASSIGNED (forced awareness!)
// Cluster: YELLOW (ama veri kaybı yok)

⚠️ Dikkat: Forced awareness kullanıyorsanız, replica sayınız zone sayınızdan az olmalıdır. 2 zone + 2 replica = 3 kopya, ama sadece 2 zone var → 1 kopya her zaman UNASSIGNED kalır.

4. Shard Allocation Filtering — Include, Exclude, Require

Filtering Nedir?

Allocation filtering, belirli shard'ların belirli node'lara gitmesini veya gitmemesini kontrol eder. Üç seviye vardır:

Index-Level Filtering

// Sadece "hot" tier node'larına yerleştir
PUT my-index/_settings
{
  "index.routing.allocation.require.data": "hot"
}

// "node-3" hariç heryere yerleştir
PUT my-index/_settings
{
  "index.routing.allocation.exclude._name": "node-3"
}

// Sadece belirli node'lara yerleştir
PUT my-index/_settings
{
  "index.routing.allocation.include._name": "node-1,node-2"
}

// IP bazlı filtreleme
PUT my-index/_settings
{
  "index.routing.allocation.include._ip": "192.168.1.10,192.168.1.11"
}

Cluster-Level Filtering

// Tüm cluster için: node-5'e yeni shard atama
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": "node-5"
  }
}
// Bu, node-5'teki mevcut shard'ları taşımaya başlar (drain)

// Node decommission — bakım için node boşaltma
PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._ip": "192.168.1.15"
  }
}

Kullanılabilir Built-in Attribute'lar

Custom Attribute ile Filtering

# elasticsearch.yml
node.attr.size: large
node.attr.environment: production
node.attr.team: search

// Sadece "large" node'lara yerleştir
PUT my-big-index/_settings
{
  "index.routing.allocation.require.size": "large"
}

// Sadece "production" environment'a yerleştir
PUT my-critical-index/_settings
{
  "index.routing.allocation.require.environment": "production"
}

// Birden fazla koşul (AND)
PUT my-index/_settings
{
  "index.routing.allocation.require.size": "large",
  "index.routing.allocation.require.environment": "production"
}

5. Disk-Based Allocation — Watermark Mekanizması

Watermark Nedir?

Disk-based allocation, node'ların disk doluluk oranına göre shard yerleşimini kontrol eder. Üç seviye vardır:

                    Disk Doluluk
  0%──────────────85%─────90%─────95%─────100%
  │   Normal       │ Low   │ High │Flood  │
  │   Allocation   │ Warn  │ Evac │Stage  │
  │   Devam        │ Dur   │ Taşı │R/O!   │

Watermark Ayarları

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "85%",
    "cluster.routing.allocation.disk.watermark.high": "90%",
    "cluster.routing.allocation.disk.watermark.flood_stage": "95%",
    "cluster.routing.allocation.disk.watermark.flood_stage.frozen": "95%",
    "cluster.info_update_interval": "30s"
  }
}

Her watermark'ın etkisi:

Flood Stage Recovery:

Flood stage tetiklenince index'ler read_only_allow_delete: true olur. Disk temizledikten sonra:

// Flood stage sonrası index'leri tekrar writable yap
PUT my-index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

// Veya tüm index'ler için
PUT _all/_settings
{
  "index.blocks.read_only_allow_delete": null
}

// Otomatik read_only kaldırma (7.4+)
// ES, disk %90 altına düşünce otomatik kaldırır
// Ama eski versiyon veya edge case'lerde elle müdahale gerekebilir

Watermark'ları Mutlak Değer ile Ayarlama

Yüzde yerine mutlak byte değeri de kullanabilirsiniz — bu durumda "kalan boş alan" anlamına gelir:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "100gb",
    "cluster.routing.allocation.disk.watermark.high": "50gb",
    "cluster.routing.allocation.disk.watermark.flood_stage": "25gb"
  }
}
// low: 100GB'dan az boş alan kalınca yeni shard atanmaz
// high: 50GB'dan az boş alan kalınca shard taşınır
// flood: 25GB'dan az boş alan kalınca read-only

Disk Durumunu İzleme

# Node bazında disk kullanımı
GET _cat/allocation?v&h=node,shards,disk.indices,disk.used,disk.avail,disk.total,disk.percent

# Çıktı:
# node     shards disk.indices disk.used disk.avail disk.total disk.percent
# node-1   245    1.2tb        1.5tb     500gb      2tb        75
# node-2   238    1.1tb        1.4tb     600gb      2tb        70
# node-3   252    1.3tb        1.6tb     400gb      2tb        80

💡 İpucu: Disk watermark'larınızı monitoring sisteminize bağlayın. %80'de alert verin ki %85'e ulaşmadan aksiyon alın. Flood stage'de zaten geç kalmış olursunuz.

6. Allocation Explain API — Neden Atanmadı?

Explain API Kullanımı

Bir shard neden UNASSIGNED kaldığını anlamak için en güçlü araç:

// Belirli bir shard'ı açıkla
GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

// İlk UNASSIGNED shard'ı otomatik açıkla
GET _cluster/allocation/explain

Explain API Çıktısı Yorumlama:

// Örnek çıktı:
{
  "index": "my-index",
  "shard": 0,
  "primary": true,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "INDEX_CREATED",
    "at": "2024-01-15T10:00:00.000Z",
    "last_allocation_status": "no_valid_shard_copy"
  },
  "can_allocate": "no",
  "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",
  "node_allocation_decisions": [
    {
      "node_id": "abc123",
      "node_name": "node-1",
      "node_decision": "no",
      "weight_ranking": 1,
      "deciders": [
        {
          "decider": "filter",
          "decision": "NO",
          "explanation": "node does not match index setting [index.routing.allocation.require.data] filters [data:\"hot\"]"
        }
      ]
    },
    {
      "node_id": "def456",
      "node_name": "node-2",
      "node_decision": "yes",
      "weight_ranking": 2,
      "deciders": [
        {
          "decider": "filter",
          "decision": "YES"
        },
        {
          "decider": "disk_threshold",
          "decision": "YES"
        }
      ]
    }
  ]
}

Bu çıktıdan anlıyoruz ki:

• Shard atanamazken node-1'de "filter" decider'ı engellemiş (hot tier gereksinimi karşılanmıyor)

• node-2'ye atanabilir

Yaygın Explain Çıktıları ve Çözümleri

1. "the shard cannot be allocated to the same node"

Primary ve replica aynı node'a konamaz.
Çözüm: Daha fazla node ekleyin veya replica sayısını azaltın.

2. "node does not match index setting filters"

Index'in allocation filter'ı node'un attribute'ıyla uyuşmuyor.
Çözüm: Node attribute veya index filter ayarını kontrol edin.

3. "the shard cannot be allocated because the disk is full"

Disk watermark aşılmış.
Çözüm: Disk temizle, eski index'leri sil, node ekle.

4. "the cluster currently has X nodes but we need Y"

Forced awareness gereksinimleri karşılanmıyor.
Çözüm: Gerekli zone'lardaki node'ları çalıştırın.

7. Reroute API — Manuel Shard Yönetimi

Reroute API Nedir?

Reroute API, shard'ları elle taşımanızı, atamanızı veya iptal etmenizi sağlar. Production'da dikkatli kullanın.

Shard Taşıma (Move)

POST _cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "my-index",
        "shard": 0,
        "from_node": "node-1",
        "to_node": "node-3"
      }
    }
  ]
}

UNASSIGNED Shard'ı Atama (Allocate)

// Stale replica'yı kabul ederek atama (veri kaybı olabilir!)
POST _cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "my-index",
        "shard": 0,
        "node": "node-2",
        "accept_data_loss": true
      }
    }
  ]
}

// Boş primary oluşturarak atama (TAMAMEN BOŞ!)
POST _cluster/reroute
{
  "commands": [
    {
      "allocate_empty_primary": {
        "index": "my-index",
        "shard": 0,
        "node": "node-2",
        "accept_data_loss": true
      }
    }
  ]
}

// Replica atama
POST _cluster/reroute
{
  "commands": [
    {
      "allocate_replica": {
        "index": "my-index",
        "shard": 0,
        "node": "node-3"
      }
    }
  ]
}

⚠️ Dikkat: allocate_stale_primary ve allocate_empty_primary veri kaybına yol açabilir. Sadece tüm kopyaların kaybolduğu ve başka çare olmadığı durumlarda kullanın.

Allocation İptal Etme

POST _cluster/reroute
{
  "commands": [
    {
      "cancel": {
        "index": "my-index",
        "shard": 0,
        "node": "node-1",
        "allow_primary": false
      }
    }
  ]
}

Dry Run — Simülasyon

// Gerçekten taşımadan sonucu gör
POST _cluster/reroute?dry_run=true
{
  "commands": [
    {
      "move": {
        "index": "my-index",
        "shard": 0,
        "from_node": "node-1",
        "to_node": "node-3"
      }
    }
  ]
}

8. Shard Recovery ve Peer Recovery

Recovery Nedir?

Recovery, bir shard'ın kullanılabilir duruma getirilme sürecidir. İki ana senaryoda gerçekleşir:

1. Node restart: Node kapanıp açıldığında shard'lar local storage'dan recover olur

2. Replica allocation: Yeni replica shard oluşturulurken primary'den kopyalanır (peer recovery)

Recovery Sürecini İzleme

# Aktif recovery işlemleri
GET _cat/recovery?v&active_only=true&h=index,shard,type,stage,source_node,target_node,bytes_percent

# Çıktı:
# index     shard type      stage     source    target    bytes_percent
# my-index  0     peer      translog  node-1    node-3    67.5%
# my-index  1     peer      index     node-2    node-3    23.1%
# logs-001  0     existing  done      n/a       node-1    100.0%

Recovery Tipleri:

Recovery Aşamaları (Stages):

Recovery Hız Ayarları

// Recovery hızını artır (maintenance window'da)
PUT _cluster/settings
{
  "transient": {
    "indices.recovery.max_bytes_per_sec": "200mb",
    "cluster.routing.allocation.node_concurrent_recoveries": 4,
    "cluster.routing.allocation.node_concurrent_incoming_recoveries": 4,
    "cluster.routing.allocation.node_concurrent_outgoing_recoveries": 4
  }
}

// Varsayılanlara dön (normal operasyonda)
PUT _cluster/settings
{
  "transient": {
    "indices.recovery.max_bytes_per_sec": "40mb",
    "cluster.routing.allocation.node_concurrent_recoveries": 2
  }
}

💡 İpucu: Node bakımında max_bytes_per_sec'i 200-500mb'a çıkarın. Recovery hızlanır, ama diğer node'ların I/O'sunu etkiler. Normal operasyonda 40-100mb yeterli.

9. Cluster Routing Allocation Settings

Allocation Kontrolü

// Allocation'ı tamamen durdur
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "none"
  }
}

// Sadece primary'lerin allocation'ına izin ver
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

// Sadece yeni primary'lerin allocation'ına izin ver
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "new_primaries"
  }
}

// Normal operasyona dön
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}

Ne zaman allocation kapatılır?

• Rolling upgrade sırasında (node restart öncesi)

• Cluster bakımında (disk değişimi, OS upgrade)

• Debugging sırasında (allocation sorunlarını izole etmek)

Delayed Allocation

Bir node düştüğünde, Elasticsearch hemen shard'ları yeniden dağıtmaya başlar. Ama node kısa sürede geri gelecekse (restart gibi), bu gereksiz yük oluşturur. Delayed allocation, bekleme süresi tanımlar:

// Index seviyesinde delayed allocation
PUT my-index/_settings
{
  "index.unassigned.node_left.delayed_timeout": "5m"
}

// Cluster seviyesinde (tüm yeni index'ler için)
PUT _cluster/settings
{
  "persistent": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

// Delayed allocation'ı bekleyen shard'ları gör
GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,unassigned.for

Varsayılan: 1 dakika. Production'da 5-10 dakika önerilir — rolling restart sırasında gereksiz data transfer'i önler.

Rebalancing Ayarları

// Rebalancing'i kontrol et
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.rebalance.enable": "all",
    "cluster.routing.allocation.allow_rebalance": "indices_all_active",
    "cluster.routing.allocation.cluster_concurrent_rebalance": 2,
    "cluster.routing.allocation.balance.shard": 0.45,
    "cluster.routing.allocation.balance.index": 0.55,
    "cluster.routing.allocation.balance.threshold": 1.0
  }
}

10. Transient vs Persistent Settings

Fark Nedir?

// PERSISTENT — Cluster restart'ta kalıcı
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}

// TRANSIENT — Cluster restart'ta kaybolur
PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

Öncelik sırası:

1. Transient settings      (en yüksek öncelik)
2. Persistent settings
3. elasticsearch.yml
4. Varsayılan değerler     (en düşük öncelik)

⚠️ Dikkat: Elasticsearch 8.x'te transient settings deprecated olarak işaretlendi. Yeni projelerde sadece persistent kullanın. Transient, geçici bakım işlemleri için hâlâ kullanılabilir ama uzun vadede kaldırılacak.

Hangi Ayarı Nerede Kullanmalı?

# Mevcut cluster settings'leri gör
GET _cluster/settings?include_defaults=true&flat_settings=true

# Sadece değiştirilmiş ayarları gör
GET _cluster/settings?flat_settings=true

# Bir ayarı sıfırla (null yaparak)
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": null
  }
}

11. Shard Allocation Sorun Giderme Flowchart

Cluster YELLOW veya RED?
        │
        ▼
UNASSIGNED shard var mı?
├── Hayır → Başka sorun (node down, vb.)
└── Evet
        ↓
    GET _cluster/allocation/explain
        │
        ├── "disk watermark" → Disk temizle / node ekle
        │
        ├── "filter" → Node attribute kontrol et
        │     └── GET _cat/nodeattrs?v
        │
        ├── "same shard" → Yeterli node yok
        │     └── Node ekle veya replica azalt
        │
        ├── "awareness" → Zone/rack eksik
        │     └── Eksik zone'a node ekle
        │
        ├── "no valid shard copy" → Veri kaybı!
        │     └── Snapshot'tan restore et veya
        │         allocate_empty_primary kullan (son çare)
        │
        └── "delayed" → Bekleme süresi dolmadı
              └── Bekle veya timeout'u kısalt

Özet

Bu derste öğrendiklerimizi toplayalım:

1. Allocation mekanizması, master node'daki 20+ "decider" ile çalışır. Her shard için en uygun node seçilir — disk, zone, filtre, shard limiti hepsi hesaba katılır.

2. Allocation awareness, shard'ları rack/zone/region'a göre dağıtır. Normal awareness "best effort", forced awareness "katı kural" — tanımlı zone yoksa shard UNASSIGNED kalır.

3. Allocation filtering (include/exclude/require) ile shard'ları belirli node'lara yönlendirebilir veya engelleyebilirsiniz. Hot-warm-cold tier mimarisinin temeli budur.

4. Disk watermark'lar (%85 low, %90 high, %95 flood) disk doluluk yönetiminin güvenlik ağıdır. Flood stage'de index'ler read-only olur — acil müdahale gerekir.

5. Allocation explain API, UNASSIGNED shard'ların "neden atanmadığını" açıklar. Troubleshooting'in ilk adımı her zaman _cluster/allocation/explain olmalıdır.

6. Recovery ayarları (bandwidth, concurrency) ve delayed allocation production'da doğru yapılandırılmalıdır. Rolling restart'larda gereksiz GB'larca data transfer'i önlemek için delayed timeout'u 5-10 dakikaya ayarlayın.