"Mevcut üretim EL5 sunucularımızı EL6'ya yükseltebilir miyiz?"

Tamamen farklı ortamlara sahip iki müşteriden gelen basit bir istek, benim "en iyi uygulamalarım" cevabını verdi, ancak tüm sistemlerinizin koordineli bir şekilde yeniden kurulmasını gerektirecek ...

Her iki müşteri de sistemlerini tam olarak yeniden inşa etmenin aksama süresi ve kaynak nedenlerinden dolayı kabul edilemez bir seçenek olduğunu düşünüyor ... Neden sistemlerin tamamen yeniden kurulmasının gerekli olduğunu sorduğumda, bunun ötesinde iyi bir cevabım yoktu, "olduğu gibi ..."

Yapılandırma yönetimi ("Her şeyi kuklalaştır " her zaman geçerli değildir ) ya da müşterilerin nasıl daha iyi planlama yapmaları gerektiği konusunda yanıtlar vermeye çalışmıyorum . Bu, üretim kapasitesinde büyümüş ve büyümüş ortamların gerçek dünya örneğidir, ancak işletim sistemlerinin bir sonraki sürümüne geçmek için temiz bir yol görmezler.

Ortam A: 40 x Red Hat Enterprise Linux 5.4 ve 5.5 web, veritabanı sunucuları ve posta sunucularıyla, Java web uygulama yığını çalıştıran, yazılım yük dengeleyici ve Postgres veritabanlarıyla
kar amacı gütmeyen bir organizasyon . Tüm sistemler, her biri HA, DRS vb. Olmak üzere farklı konumlardaki iki VMWare vSphere kümesinde sanallaştırılmıştır.

Çevre B: Üretim ticaret operasyonları yürüten, kurum içi geliştirme ve arka ofis fonksiyonlarını destekleyen, birden fazla ortak lokasyondaki tesislerinde 200 x CentOS 5.x sistemli
yüksek frekanslı finansal ticaret şirketi . Ticaret sunucuları çıplak metal emtia sunucusu donanımı üzerinde çalışıyor. Mesaj gecikmesini azaltmak için sayısız , kesilmiş ciltleme ve sürücü ayarlamaları vardır. Bazılarının özel ve / veya gerçek zamanlı çekirdekleri vardır. Geliştirici iş istasyonları da CentOS'un benzer bir sürümünü çalıştırıyor.sysctl.confrtctl

Her iki durumda da, ortamlar olduğu gibi iyi çalışıyor. Yükseltme isteği, EL6'da bulunan daha yeni bir uygulamaya veya özelliğe duyulan ihtiyaçtan kaynaklanıyor.

• Kar amacı gütmeyen firma için Apache'ye, çekirdeğe ve geliştiricileri mutlu edecek bazı şeylere bağlı.
• Ticaret firmasında, çekirdeğin, ağ yığınının ve geliştiricilerin mutlu olmasını sağlayacak GLIBC'nin bazı geliştirmeleri hakkında.

Her ikisi de , işletim sistemini büyük ölçüde değiştirmeden kolayca paketlenemeyen veya güncellenemeyen şeylerdir .

Bir sistem mühendisi olarak, Red Hat'in büyük sürüm sürümleri arasında geçiş yaparken tam yeniden oluşturma önerisinde bulunduğunu takdir ediyorum. Temiz bir başlangıç ​​sizi yeniden yönlendirmeye zorlar ve yol boyunca yapılanmaya dikkat edin.

Müşterilerin iş ihtiyaçlarına duyarlı olmak, bunun neden bu kadar zor bir görev olması gerektiğini merak ediyorum . RPM paketleme sistemi, yerinde yükseltmelerle başa çıkabilmekten daha fazlasıdır, ancak sizi /bootdaha az alan gerektirir : daha fazla alan, yeni varsayılan dosya sistemleri, RPM muhtemelen orta seviyedeki yükseltme, kullanımdan kaldırılmış ve geçersiz kılan paketler ...

Buradaki cevap ne? Diğer dağıtımlar (.deb-tabanlı, Arch ve Gentoo) bu yeteneğe veya daha iyi bir yola sahip gibi görünüyor. Diyelim ki bu görevi başarmanın kesinti olduğunu doğru şekilde bulalım :

• EL7 piyasaya sürüldüğünde ve stabilize olduğunda bu istemciler aynı sorunu önlemek için ne yapmalı?
• Yoksa bu, insanların birkaç yılda bir yeniden inşa etmek için kendilerini istifa etmesi gereken bir durum mu?
• Enterprise Linux geliştikçe bu daha da kötüleşti gibi görünüyor ... Yoksa sadece hayal mi ediyorum?
• Bu Red Hat ve türev işletim sistemlerini kullanmaktan kimseyi caydırdı mı?

Sanırım yapılandırma yönetimi açısı var, ancak gördüğüm çoğu Kukla kurulumunun yüksek düzeyde özelleştirilmiş uygulama sunucularına sahip ortamlara iyi dönüşmediğini ( Ortam B'ninifconfig çıktısı böyle gözüken tek bir sunucuya sahip olabilir ). Yine de, organizasyonların RHEL'in ana sürümdeki çarpma adımlarını aşmasına yardımcı olmak için yapılandırma yönetiminin nasıl kullanılabileceğine dair işitme önerileri ilginç olur.

(Yazarın Notu: Bu cevap RHEL 6 ve önceki sürümlere atıfta bulunmaktadır. RHEL 7 şimdi, ayrıntıları sonunda olan RHEL 6'dan tamamen desteklenen bir yükseltme yoluna sahiptir.)

Başlamak için, yerinde yükseltmeyi gerçekleştirmenin iki yolu olduğunu unutmayın :

1. Kurulum DVD'sini bırakın (veya DVD görüntüsünü iLO / iDRAC aracılığıyla kullanın), önyükleyin ve örneğin Yükseltme öğesini seçin linux upgradeany.
2. redhat-releaseRPM'yi manuel olarak güncelleyin , çalıştırın yum distro-sync(bu biraz fazla basitleştirilmiştir) ve yeniden başlatın.

Yöntem 1 yalnızca desteklenmiyor. Yöntem 2, Gerçek Kovboylar içindir. Tavsiye edilen yeni kurulumlara ek olarak, her ikisini de yaptım ...

Desteğe ihtiyacım var mı?

Desteğin dünyamızda iki tamamlayıcı anlamı vardır. Birincisi, bir ürünün belirli bir özelliğe sahip olmasıdır (örn. "Postfix, SMTP'yi destekler"). İkincisi, satıcının sizinle bu konuda konuşmasıdır. Bu tanımın ne anlama geldiği her zaman bağlamdan açık değildir.

Bir görevi başarmak için, ilk bakışta açıkça desteğe ihtiyacınız vardır. Satıcı desteğinin geldiği yer, sorunları çözmenize ve hangi özelliklerin olması veya iyileştirilmesi gerektiğine dair satıcıya geri bildirimde bulunmanıza yardımcı olmaktır. Birçok site, satıcıya verebileceğinden daha hızlı, hatta daha ucuz olabilecek sorunları çözmek için kurum içi uzmanlığa sahip olduklarında satıcı desteği için bir servet öder. Satıcı desteğini satın alıp almayacağınız nihayetinde karar vermeniz gereken bir işletme kararıdır (veya yönetimi öneriniz).

Yerinde yükseltme neden yapılmıyor?

Bu Red Hat bu konuda ne diyor :

Red Hat, Red Hat Enterprise Linux'un büyük sürümleri arasında yerinde yükseltmeyi desteklemez. Büyük bir sürüm tam sayı sürüm değişikliği ile gösterilir. Örneğin, Red Hat Enterprise Linux 5 ve Red Hat Enterprise Linux 6, Red Hat Enterprise Linux'un başlıca sürümleridir.

Başlıca sürümlerdeki yerinde yükseltme, tüm sistem ayarlarını, hizmetleri veya özel yapılandırmaları korumaz. Sonuç olarak, Red Hat bir büyük versiyondan diğerine yükseltme yaparken yeni kurulumlar yapılmasını şiddetle tavsiye eder.

Daha da uyardılar:

Ancak, sisteminizi yükseltmeyi seçmeden önce aşağıdaki sınırlamalara dikkat edin:

• Bireysel paket konfigürasyon dosyaları, çeşitli konfigürasyon dosyası formatlarındaki veya düzenindeki değişikliklerden dolayı yükseltme yaptıktan sonra çalışmayabilir veya çalışmayabilir.
• Red Hat'in katmanlı ürünlerinden birine (Cluster Suite gibi) sahipseniz, Red Hat Enterprise Linux yükseltmesi tamamlandıktan sonra manuel olarak yükseltilmesi gerekebilir.
• Üçüncü taraf veya ISV uygulamaları yükseltme işleminden sonra düzgün çalışmayabilir.

Elbette, daha sonra gerçekten yapmak istemeniz durumunda, yöntem 1 aracılığıyla yerinde yükseltme işleminin nasıl yapıldığını açıklarlar. Bu özellik var ve Red Hat geliştirme zamanını buna dahil ediyor, bu yüzden bu özelliğin var olduğu destekleniyor. Fakat eğer bir şeyler ters giderse, Red Hat size yeni bir kurulum yapmanızı söyler; yükseltme sonucunda kırılan şeyler için satıcı desteği sağlamazlar.

Kayıt için, kendimi çözemediğim bir RHEL / CentOS veya Fedora sisteminin yerinde geliştirilmesinde hiçbir zaman sorun yaşamadım. Tipik problemler, yeniden adlandırılmış paketlerden, üçüncü taraf depolarından ve bir paketin i386 ve x86_64 mimarileri arasındaki zaman zaman versiyon uyumsuzluğundan kaynaklanmaktadır. Yükleyici bu işlemlerde biraz daha iyidir yum, sanırım.

Nasıl yükseltmeliyim?

Genelde insanları her 3-4 yılda bir RHEL sistemlerini bir ana versiyondan diğerine güncellemek için bir bakım penceresinde planlamaları gerektiği konusunda uyarıyorum . Yükseltmeler genel olarak sorunsuz ilerlerken, beklenmeyenler her zaman olabilir.

Her iki ortamınız için de yerinde bir güncellemenin işe yarayacağını umuyorum, ancak öncelikle iyice test etmenizi şiddetle tavsiye ediyorum. P2V sunucuların temsili bir örneğidir ve ne gibi sorunlarla karşılaşacağınızı görmek için sanal sistemlerde yerinde yükseltme işlemini gerçekleştirin. Daha sonra ne olacağını daha iyi bilerek temel üretim güncellemesini planlayabilirsiniz.

Burada olduğu gibi büyük bir dağıtım için, Limoncelli'nin "bir-bazı-bir" yaklaşımını kullanmayı düşünün. Bir makineyi yükseltin, sorunların neler olduğunu görün, bunları çözün, ardından küçük bir makine grubunu yükseltirken öğrenilen dersleri kullanın, öğrenilen dersleri tekrarlayın, sonra tüm bükülmelerin çalıştığına inandığınızda büyük partileri yükseltin.

Bunun gibi bir zamanda, uygulama dağıtım işleminize uzunca bir göz atmanızı öneririm. Tek bir komutla başlatabilmeniz için yeterince otomatik değilse ve uygulamanın doğru bir şekilde uygulandığından emin olmanız gerektiğinden emin olabilirseniz, belki de geliştiricilerin bu konuda çalışmaya başlaması gerekir. Bu tür bir dağıtım işlemine sahip olmak, EL'in daha yeni bir sürümünün yeni bir kurulumunu yapmayı ve ardından dağıtmayı çok kolaylaştıracaktır.

Anahtarlama dağıtımları yardımcı olur mu?

Debian tabanlı dağıtımlar yerinde destekleme yöntemini desteklemektedir ve çoğunlukla çalışır, ancak sorunlardan bağışıklık kazanmaz. Örneğin Ubuntu 10.04 LTS'den 12.04 LTS'ye , örneğin desteklenen yöntemle yükseltme yapan insanlar için birçok şey kırıldı . Debian veya Canonical'ın bu özelliği “desteklemeye”, yani çalıştığından emin olmak için yeterli miktarda geliştirme zamanı harcadığı açık değildir. Birinin elini tutmasını istiyorsanız, hala bu dağıtım için satıcı desteği almanız gerekiyor. Bu yüzden böyle bir dağılıma geçmekten çok para kazanacağınızdan şüpheliyim.

Gentoo veya Arch gibi bir yayın dağıtımına geçerek kazanabilirsiniz. Ancak, bu aynı zamanda sizi problemlere karşı bağışıklık kazanmaz; bu yalnızca sunucunun kullanım ömrü boyunca sürekli olarak yükseltme sorunları ile ilgilenmeniz gerektiği anlamına gelir (örneğin, siz veya geliştiriciler iyi planlanmış bir dağıtım yükseltme zamanında bir kerede değil, sistemde bir şeyi güncellemeye karar verdiğinizde). Ayrıca destek sağlayacak hiçbir satıcınız yok.

Gelecek ne gösterir?

Fedora Projesi, yerinde yükseltmeleri geliştirmek için bir araç üzerinde çalışıyor. Fedora 18 ile başlayan, adı preupgradeterk edilmiş ve yerine fedup adı verilen yeni bir araç olan bir aracı vardı . Bu, RHEL7'ye eklenmiştir ve şimdi yerinde yükseltmeler , en azından RHEL 6'dan RHEL 7'ye kadar tam desteğe sahiptir . Kendi tecrübelerime dayanarak feduphala bazı sapkınlıklara rağmen, çok kullanışlı bir araç olarak şekillendiğini söyleyebilirim .

CentOS aynı zamanda bir yuvarlanma serbest bırakma havuz türünü deniyor, ancak yalnızca küçük sürümler için de geçerlidir (örn. 6.3-6.4).

Son paragrafını benim almam:

Sanırım yapılandırma yönetimi açısı var, ancak gördüğüm çoğu Kukla kurulumunun yüksek düzeyde özelleştirilmiş uygulama sunucularına sahip ortamlara iyi dönüşmediğini (Ortam B'nin ifconfig çıktısı böyle görünen tek bir sunucuya sahip olabilir). Yine de, organizasyonların RHEL'in ana sürümdeki çarpma sürecini aşmasına yardımcı olmak için yapılandırma yönetiminin nasıl kullanılabileceğine dair işitme önerileri ilginç olur.

Yapılandırma yönetim sistemlerinin asıl değerinin, özellikle Çevre B bağlamında, onu işleten sunuculardan bağımsız olarak bir hizmet inşa etmek için araçlar sağlamaları olduğunu düşünüyorum. Bir CMS mevcut hizmetleri oluşturmak için kullanılmadıysa, o zaman hizmetleri yeniden oluşturmada pek yardımcı olmaz.

Bunun sizin acil sorununuzu çözmediğini biliyorum, ama benim için, hizmetten ziyade sunucular açısından düşünmekten kaynaklanıyor. Hizmet odaklı düşüncede, hizmetin devam ettiği sürece bireysel sunucuların kişiliğinin korunmasına gerek yoktur. Bir CMS, tüm hizmeti oluşturmak için disiplinli bir şekilde kullanılırsa, o zaman bu servisi başka bir sisteme taşımak nispeten kolay olmalıdır, çünkü makinenin tüm kişiliği CMS tarafından oluşturulacaktır.

PS Bu bağlamda ifconfig çıktısı için neyin önemli olduğundan tam olarak emin değilim - bir yapılandırma dosyası ve bazı komut dosyaları tarafından üretilir (aksi takdirde önyüklemede orada olmaz) ve bunlar gerekirse bir CMS tarafından yönetilebilir.