Mimari ve çalışma modeli
Multipart upload, büyük nesneyi ayrı part'lara böler; her part bağımsız yüklenir ve ETag/part numarasıyla kaydedilir. İstemci CompleteMultipartUpload çağrısında sıralı part listesini gönderdiğinde nesne görünür olur. Başlatılmış fakat tamamlanmamış yükleme normal nesne listesinde görünmeyebilir; depolama tüketmeye ve maliyet üretmeye devam edebilir.
Ağ kesintisi sonrasında yeniden deneme aynı upload ID ve part numarasıyla yapılırsa part değiştirilebilir; yeni bir upload ID açılırsa eski part'lar artık kalır. ETag'i her sistemde yalın MD5 kabul etmeyin: şifreleme, checksum seçimi ve S3 uyumlu ürün davranışı farklı olabilir. Tamamlama öncesi ListParts sonucu istemcinin yerel manifestiyle karşılaştırılmalıdır.
Temizlik politikası, etkin ve terk edilmiş yüklemeyi yalnız yaşa göre ayırır. Çok uzun süren arşiv yüklemeleri için yaşam döngüsü eşiği gerçek maksimum transfer süresinden büyük olmalıdır. Abort işlemi yetkilendirme, yarış durumu ve devam eden part yüklemeleri nedeniyle yeniden doğrulama gerektirir; silme sonrası ListMultipartUploads ile kanıt toplanmalıdır.
- 1CreateMultipartUpload ve upload ID
- 2Part yükleme ve checksum
- 3ListParts ile manifest doğrulama
- 4Complete veya kontrollü Abort
Tasarım parametreleri
- Part boyutu ve sayısı
- Ağ yeniden deneme maliyeti, paralellik, ürün limitleri ve belleği birlikte belirler.
- Checksum/ETag
- İstemci ve hedefin desteklediği checksum algoritmasını açıkça seçin; ETag anlamını varsaymayın.
- Paralellik
- Hat kapasitesi, disk okuma hızı, CPU ve hedef throttling sınırına göre ayarlayın.
- Artık yükleme eşiği
- Yaşam döngüsü günü, en uzun meşru yükleme süresi ve bakım penceresinden büyük olmalıdır.
Hesap ve uygulama örneği
800 GiB dosya 128 MiB part'lara ayrılırsa 6.400 part oluşur. Sekiz paralel işçi ve işçi başına 256 MiB tampon yaklaşık 2 GiB istemci belleği ister. Hat 1 Gb/s ise teorik minimum yaklaşık 1,8 saat, protokol ve yeniden denemelerle daha uzundur; bir günlük abort eşiği planlı yavaş bağlantı için riskli olabilir.
ListMultipartUploads 37 kayıt, uygulama işi ise 4 aktif upload gösteriyorsa kalan 33 kayıt yaştan önce sahiplik ve son part zamanı ile eşleştirilir. Pilot olarak tek terk edilmiş upload abort edilir, depolama metriği ve liste sonucu doğrulanır; ardından yaşam döngüsü kuralı uygulanır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
aws s3api list-multipart-uploads --bucket lab-bucket --prefix archive/
aws s3api list-parts --bucket lab-bucket --key archive/db.dump --upload-id UPLOAD_ID
aws s3api abort-multipart-upload --bucket lab-bucket --key archive/db.dump --upload-id UPLOAD_ID
aws s3api list-multipart-uploads --bucket lab-bucket --prefix archive/Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| InvalidPart veya InvalidPartOrder | Tamamlama manifestinde eksik, farklı ETag'li veya sırasız part olabilir. | ListParts çıktısını yerel part numarası, boyut ve ETag/checksum kaydıyla karşılaştırın. |
| Depolama artıyor, nesne sayısı değişmiyor | Tamamlanmamış multipart upload'lar birikiyor olabilir. | ListMultipartUploads sonucunu yaş, prefix ve başlatan kimlikle gruplayın. |
| Abort sonrası part'lar görünüyor | Abort ile eşzamanlı part yüklemesi veya eventual liste gecikmesi olabilir. | Yeni yüklemeyi durdurup aynı upload ID'yi tekrar listeleyin ve gerekirse abort'u yineleyin. |
Kabul ve doğrulama kontrolleri
- Aktif upload ID'lerini uygulama işleriyle eşleyin.
- Part boyutu ve maksimum part sayısı hesabını doğrulayın.
- ListParts ile yerel manifesti tamamlamadan önce karşılaştırın.
- Checksum davranışını hedef ürün sürümünde test edin.
- Tek artık upload için abort ve kapasite geri kazanımını pilotlayın.
- Yaşam döngüsü eşiğini en uzun meşru transfer süresine göre doğrulayın.
İlgili kavramlar
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Saklama politikası ve kapasite
Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.