Lsv3, Lasv3 ve Lsv2 serisi Linux VM'lerinde performansı iyileştirme

Dikkat

Bu makale, Kullanım Süresi Sonu (EOL) durumu olan bir Linux dağıtımı olan CentOS'a başvurur. Lütfen kullanımınızı göz önünde bulundurun ve uygun şekilde planlayın. Daha fazla bilgi için bkz . CentOS Kullanım Süresi Sonu kılavuzu.

Şunlar için geçerlidir: ✔️ Linux VM'leri ✔️ Tekdüzen ölçek kümeleri

Lsv3, Lasv3 ve Lsv2 serisi Azure Sanal Makineler (Azure VM'leri), çok çeşitli uygulamalar ve sektörlerde yerel depolamada yüksek G/Ç ve aktarım hızı gerektiren çeşitli iş yüklerini destekler. L serisi Büyük Veri, SQL, NoSQL veritabanları, veri ambarı ve Cassandra, MongoDB, Cloudera ve Redis gibi büyük işlem veritabanları için idealdir.

Linux'ta iş ortaklarıyla çalışma nedeniyle çeşitli derlemeler Azure Market kullanılabilir. Bu derlemeler Lsv3, Lasv3 ve Lsv2 serisi performans için iyileştirilmiştir. Kullanılabilir derlemeler aşağıdaki ve sonraki sürümlerini içerir:

• Ubuntu 16.04
• RHEL 8.0 ve CentOS, Rocky Linux ve Alma Linux dahil klonlar
• Debian 9
• SUSE Linux 15
• Oracle Linux 8.0

Bu makale, iş yüklerinizin ve uygulamalarınızın VM'lerde tasarlanan maksimum performansa ulaşmasını sağlamaya yönelik ipuçları ve öneriler sağlar.

AMD EPYC™ yonga kümesi mimarisi

Lasv3 ve Lsv2 serisi VM'ler Zen mikro mimarisini temel alan AMD EPYC™ sunucu işlemcileri kullanır. AMD, KULLANıMA hazır, paket içi ve çok paketli iletişimler için kullanılabilen NUMA modeli için ölçeklenebilir ara bağlantı olarak EPYC™ için Infinity Fabric (IF) geliştirdi. Intel modern monolitik kalıp işlemcilerde kullanılan QPI (Hızlı Yol Ara Bağlantısı) ve UPI (Ultra-Path Interconnect) ile karşılaştırıldığında, AMD'nin çok NUMA küçük kalıp mimarisi hem performans avantajları hem de zorluklar getirebilir. Bellek bant genişliği ve gecikme kısıtlamalarının gerçek etkileri, çalışan iş yüklerinin türüne bağlı olarak değişebilir.

Performansı en üst düzeye çıkarmak için ipuçları

• İş yükünüz için özel bir Linux GuestOS yüklüyorsanız Hızlandırılmış Ağ varsayılan olarak kapalıdır. Hızlandırılmış Ağ'ı etkinleştirmeyi planlıyorsanız, en iyi performans için VM oluşturma sırasında etkinleştirin.
• Maksimum performans elde etmek için cihaz başına derin kuyruk derinliğiyle birden çok iş çalıştırın.
• Etkin iş yükleri sırasında NVMe yönetici komutlarını (örneğin, NVMe SMART bilgi sorgusu vb.) NVMe G/Ç komutları ile karıştırmaktan kaçının. Lsv3, Lasv3 ve Lsv2 NVMe cihazları Hyper-V NVMe Direct teknolojisi tarafından desteklenir ve bu teknoloji, herhangi bir NVMe yönetici komutu beklemede olduğunda "yavaş moda" geçer. Lsv3, Lasv3 ve Lsv2 kullanıcıları, NVMe G/Ç performansında önemli bir performans düşüşü görebilir.
• Lsv2 kullanıcılarının, uygulamalarının NUMA benzitesine karar vermek üzere veri sürücüleri için VM'nin içinden bildirilen cihaz NUMA bilgilerine (0'ın tümü) güvenmeleri önerilmez. Daha iyi performans için önerilen yol, mümkünse iş yüklerini CPU'lara yaymaktır.
• Lsv3, Lasv3 ve Lsv2 VM NVMe cihazı için G/Ç kuyruk çifti başına desteklenen en fazla kuyruk derinliği 1024'dür. Lsv3, Lasv3 ve Lsv2 kullanıcılarının kuyruk tam koşullarını tetiklememek için (yapay) karşılaştırma iş yüklerini 1024 veya daha düşük kuyruk derinliğiyle sınırlamaları önerilir ve bu da performansı düşürebilir.
• En iyi performans, G/Ç bölümleme olmayan, dosya sistemi olmayan, RAID yapılandırması olmayan ham NVMe cihazlarının her birine doğrudan yapıldığında elde edilir. Test oturumuna başlamadan önce NVMe cihazlarının her birinde çalıştırarak blkdiscard yapılandırmanın bilinen bir yeni/temiz durumda olduğundan emin olun. Karşılaştırma sırasında en tutarlı performansı elde etmek için, tüm cihazların LBA'larına SNIA Katı Hal Depolama Kurumsal Performans Testi Belirtimi'nde tanımlandığı şekilde iki kez rastgele yazmalar vererek test etmeden önce NVMe cihazlarının ön koşulunu almanız önerilir.

Yerel NVMe depolamayı kullanma

Tüm Lsv3, Lasv3 ve Lsv2 VM'lerinde 1,92 TB NVMe diskinde yerel depolama kısa ömürlüdür. VM'nin standart olarak başarılı bir şekilde yeniden başlatılması sırasında yerel NVMe diskinde bulunan veriler kalıcı hale getirilir. VM yeniden dağıtılırsa, serbest bırakılırsa veya silinirse veriler NVMe'de kalıcı olmaz. Başka bir sorun VM'nin veya üzerinde çalıştığı donanımın iyi durumda olmaması durumunda veriler kalıcı olmaz. Senaryo oluştuğunda, eski konak üzerindeki tüm veriler güvenli bir şekilde silinir.

Vm'nin farklı bir konak makineye taşınması gerektiği durumlar da vardır, örneğin planlı bir bakım işlemi sırasında. Zamanlanmış Olaylar ile planlı bakım işlemleri ve bazı donanım hataları beklenebilir. Tahmin edilen bakım ve kurtarma işlemlerinde güncel kalmak için Zamanlanmış Olaylar'ı kullanın.

Planlı bir bakım olayının vm'nin boş yerel disklere sahip yeni bir konakta yeniden oluşturulmasını gerektirmesi durumunda, verilerin yeniden eşitlenmesi gerekir (eski konaktaki tüm veriler güvenli bir şekilde silinirken). Lsv3, Lasv3 ve Lsv2 serisi VM'ler şu anda yerel NVMe diskinde dinamik geçişi desteklemediğinden bu senaryo oluşur.

Planlı bakım için iki mod vardır.

Standart VM müşteri tarafından denetlenen bakım

• VM, 30 günlük bir süre boyunca güncelleştirilmiş bir konağa taşınır.
• Lsv3, Lasv3 ve Lsv2 yerel depolama verileri kaybolabileceğinden, olay öncesinde yedeklenen veriler önerilir.

Otomatik bakım

• Müşteri tarafından denetlenen bakımlar müşteri tarafından yürütülmezse veya sıfır günlük güvenlik olayı gibi acil durum yordamları nedeniyle gerçekleşir.
• Müşteri verilerini korumaya yöneliktir, ancak VM'nin donması veya yeniden başlatılması riski küçüktür.
• Lsv3, Lasv3 ve Lsv2 yerel depolama verileri kaybolabileceğinden, olay öncesinde yedeklenen veriler önerilir.

Yaklaşan hizmet olayları için denetimli bakım işlemini kullanarak güncelleştirme için size en uygun zamanı seçin. Etkinlik öncesinde verilerinizi premium depolama alanında yedekleyin. Bakım olayı tamamlandıktan sonra, verilerinizi yenilenen Lsv3, Lasv3 ve Lsv2 VM'leri yerel NVMe depolama alanına döndürebilirsiniz.

Yerel NVMe disklerindeki verileri koruyan senaryolar şunlardır:

• VM çalışıyor ve iyi durumda.
• VM yerinde yeniden başlatılır (siz veya Azure tarafından).
• VM duraklatılır (serbest bırakma olmadan durdurulur).
• Planlı bakım bakım işlemlerinin çoğu.

Müşteriyi korumak için verileri güvenli bir şekilde silen senaryolar şunlardır:

• VM yeniden dağıtılır, durdurulur (serbest bırakılır) veya silinir (sizin tarafınızdan).
• VM iyi durumda değil hale gelir ve bir donanım sorunu nedeniyle başka bir düğüme hizmet vermek zorunda.
• VM'nin bakım için başka bir ana bilgisayara taşınmasını gerektiren planlı bakım bakım işlemlerinden birkaçı.

Sık sorulan sorular

Bu seriler hakkında sık sorulan sorular aşağıdadır.

L serisi VM'leri dağıtmaya Nasıl yaparım? başladı?

Diğer vm'ler gibi Portal, Azure CLI veya PowerShell kullanarak vm oluşturun.

Tek bir NVMe disk hatası konak üzerindeki tüm VM'lerin başarısız olmasına neden oluyor mu?

Donanım düğümünde bir disk hatası algılanırsa, donanım başarısız durumdadır. Bu sorun oluştuğunda, düğümdeki tüm VM'ler otomatik olarak serbest bırakılır ve iyi durumdaki bir düğüme taşınır. Lsv3, Lasv3 ve Lsv2 serisi VM'ler için bu sorun, müşterinin başarısız düğümdeki verilerinin de güvenli bir şekilde silindiği anlamına gelir. Müşterinin verileri yeni düğümde yeniden oluşturması gerekir.

blk_mq ayarlarını değiştirmem gerekiyor mu?

RHEL/CentOS 7.x, NVMe cihazları için otomatik olarak blk-mq kullanır. Yapılandırma değişikliği veya ayarı gerekmez.

Sonraki adımlar

Bkz. Azure'da depolama performansı için iyileştirilmiş tüm VM'lerin belirtimleri