Şu anda bir mysql sunucusuna ve dosya sunucusuna erişen birden çok web sunucusu kullanıyoruz. Buluta geçmeye bakarak, aynı kurulumu kullanabilir ve EBS'yi birden çok makine örneğine ekleyebilir miyim veya başka bir çözüm nedir?
Şu anda bir mysql sunucusuna ve dosya sunucusuna erişen birden çok web sunucusu kullanıyoruz. Buluta geçmeye bakarak, aynı kurulumu kullanabilir ve EBS'yi birden çok makine örneğine ekleyebilir miyim veya başka bir çözüm nedir?
Yanıtlar:
GÜNCELLEME (Nisan 2015) : Bu kullanım durumu için, tam olarak istediğiniz şekilde çoğaltılmak üzere tasarlanmış yeni Amazon Elastik Dosya Sistemi'ne (EFS) bakmaya başlamalısınız . EFS ve EBS arasındaki temel fark, farklı soyutlamalar sağlamalarıdır: EFS, NFSv4 protokolünü ortaya koyarken, EBS ham blok IO erişimi sağlar.
Aşağıda, ham blok cihazını birden çok makineye güvenli bir şekilde monte etmenin neden mümkün olmadığına dair orijinal açıklamamı bulacaksınız.
ORİJİNAL POST (2011):
Birden fazla örneğe eklenmiş bir EBS birimi alabilseniz bile, _REALLY_BAD_IDEA_ olur. Kekoa'dan alıntı yapmak gerekirse, "bu aynı anda iki bilgisayarda bir sabit disk kullanmak gibidir"
Bu neden kötü bir fikir? ... Birden fazla örneğe birim ekleyememenizin nedeni, EBS'nin müşterilerin ext2 / ext3 / etc gibi bir dosya sistemini çalıştırdığı bir "blok depolama" soyutlaması sağlamasıdır. Bu dosya sistemlerinin çoğu (ör. Ext2 / 3, FAT, NTFS, vb.) Blok aygıta özel erişimleri olduğu varsayılarak yazılmıştır. Aynı dosya sistemine erişen iki örnek neredeyse kesinlikle gözyaşı ve veri bozulmasıyla sonuçlanacaktır.
Başka bir deyişle, bir EBS biriminin çift bağlanması, yalnızca bir blok aygıtını birden çok makine arasında paylaşmak üzere tasarlanmış bir küme dosya sistemi çalıştırıyorsanız işe yarayabilir. Dahası, bu bile yeterli olmaz. EBS'nin bu senaryo için test edilmesi ve diğer paylaşılan blok cihazı çözümleriyle aynı tutarlılık garantileri sağlamasını sağlamak gerekir ... yani, blokların Dom0 çekirdeği, Xen katmanı gibi ara paylaşılmayan düzeylerde önbelleğe alınmaması, ve DomU çekirdeği. Ve sonra, birden çok istemci arasında blokları senkronize etmenin performansla ilgili hususları var - kümelenmiş dosya sistemlerinin çoğu, en iyi çaba gerektiren bir emtia ethernet'i değil, yüksek hızlı adanmış SAN'lar üzerinde çalışmak üzere tasarlanmıştır. Kulağa çok basit geliyor, ama istediğin şey çok önemsiz bir şey.
Alternatif olarak, veri paylaşımı senaryosunuzun NFS, SMB / CIFS, SimpleDB veya S3 olup olmadığına bakın. Bu çözümlerin tümü, paylaşılan bir blok aygıt alt sistemine sahip olmadan dosyaları paylaşmayı amaçlayan daha yüksek katman protokolleri kullanır. Çoğu zaman böyle bir çözüm aslında daha verimlidir.
Sizin durumunuzda, birden çok web kullanıcı arabirimi tarafından erişilen tek bir MySql örneğine / dosya sunucusuna sahip olabilirsiniz. Bu dosya sunucusu, verilerini bir EBS biriminde depolayabilir ve gece anlık görüntü yedeklemeleri almanıza olanak tanır. Dosya sunucusunu çalıştıran örnek kaybolursa, EBS birimini ayırabilir ve yeni bir dosya sunucusu örneğine yeniden bağlayabilir ve dakikalar içinde yedekleyip çalıştırabilirsiniz.
"Dosya sistemi olarak S3 gibi bir şey var mı?" - Evet ve hayır. Evet, s3fs gibi "tamam" olarak çalışan 3. taraf çözümleri var , ancak başlık altında hala her okuma / yazma için nispeten pahalı web hizmeti çağrıları yapmak zorundalar. Paylaşılan araçlar için, harika çalışıyor. HPC dünyasında gördüğünüz kümelenmiş FS kullanımı için bir şans değil. Daha iyisini yapmak için, NFS gibi ikili bağlantı odaklı bir protokol sağlayan yeni bir hizmete ihtiyacınız olacaktır. Makul bir performans ve davranışa sahip bu tür çok bağlantılı bir dosya sistemi sunmak EC2 için BÜYÜK bir özellik eklentisidir. Uzun zamandır Amazon'un böyle bir şey inşa etmesini savunuyorum.
Bu artık AWS Nitro'da aynı Kullanılabilirlik Alanı içinde çalışan en yeni bulut sunucusu türleriyle mümkün. Bazı uyarılar var, ancak bu, EBS hızına ihtiyaç duyan ve EFS'nin mümkün olmadığı belirli kullanım durumları için harika.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html
Hayır, bu iki bilgisayarda bir sabit disk kullanmak gibidir.
Paylaşılan veriler istiyorsanız, tüm örneklerinizin erişebileceği bir sunucu ayarlayabilirsiniz. Tüm örnekleriniz için basit bir depolama alanı istiyorsanız, dağıtılan ve ölçeklenebilir verileri depolamak için Amazon'un S3 depolama hizmetini kullanabilirsiniz.
Buluta geçtiğinizde, aynı kuruluma sahip olabilirsiniz, ancak dosya sunucusunu S3 ile değiştirebilir veya tüm örneklerinizin dosya sunucunuza bağlanmasını sağlayabilirsiniz.
Çok fazla seçeneğiniz var, ancak örnekler arasında bir sabit diski paylaşmak muhtemelen en iyi seçenek değildir.
Hayır, EBS belgelerine göre: "Bir birim bir kerede yalnızca bir örneğe eklenebilir".
Paylaşılan depolama alanını şu anda nasıl kullanıyorsunuz? Sadece dosya sunucusundan dosya sunmak için, web sunucularının bu dosyaları sunması yerine belirli istekleri dosya sunucusundaki bir sürece proxy olarak sunabilmek için bir sistem kurmayı düşündünüz mü?
aws ec2 describe-volumes
bir dizi ek döndürdüğünü merak ediyor .
Yapamayacağınıza eminim, ancak bir EBS'yi klonlayabilir ve başka bir örneğe ekleyebilirsiniz.
Bu, sabit veri kümeleri için veya 'gerçek' veriler üzerinde test yapmak için yararlıdır, ancak tek bir blok deposunda 1'den fazla örneğin çalışmasına izin vermez
AWS'de MySQL Sunucusu ve Dosya Sunucusuna erişen birden fazla Web Sunucusu normaldir. Yukarıda bahsedilen mimari için izlenecek en iyi uygulamalardan bazıları şunlardır:
Nokta 1) EC2'deki MySQL, AWS'de asenkron / yarı senkronizasyon modunda Master-Slave olarak ayarlanabilir. Yüksek performanslı DB için RAID 0'da EBS-OPT + PIOPS önerilir
Nokta 2) Alternatif olarak Amazon RDS + Multi-AZ modunu kullanabilirsiniz. Okuma ölçeklendirme için MySQL RDS'ye Çoklu RDS Okuma Çoğaltma eklenebilir.
Nokta 3) EBS Volume aynı anda Birden Çok EC2'ye eklenemez. EBS kullanarak Amazon EC2'de GlusterFS tabanlı Dosya sunucusu oluşturabilirsiniz. Birden çok Web Sunucusu, AWS infra üzerinde tek bir GlusterFS ile aynı anda konuşabilir.
Nokta 4) Uygulamanızın dosya deposu olarak S3 ile entegre edilmesi durumunda, mimariye getirdiği istikrar nedeniyle tercih edilir. S3'e, uygulamanızdan da S3fuse gibi araçları kullanarak erişebilirsiniz.
EBS bunun mümkün olduğunu açıkladı: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/
BT dünyasında Kümelenmiş Dosya Sistemi, Redhat GFS, Oracle OCFS2, Veritas CFS olarak bilinen bir şey var ...
Kısa cevap kategorik bir "Hayır" dır. Diğerleri yukarıda söyledi.
"Evet" diyenler soruyu değil farklı bir soruyu cevapladılar. EFS sadece bir NFS hizmetiyse, sorunun orijinal olarak belirtildiği gibi yanıt değildir. Ayrıca, EFS'nin "tüm bölgelerde dağıtılıp dağıtılmadığı" önemli değildir, çünkü kendi NFS örneğinizi oldukça yapabilir ve birden çok sunucunun NFS'yi monte etmesini sağlayabilirsiniz. Bu yeni bir şey değil, bunu 1992'de zaten yaptık. SMB ve sshfs, bunların hepsi, sürücüleri uzak bir dosya sistemi olarak monte etmenin yollarından biridir.
"Bunu neden yapmak istersiniz" ya da "hepsi gözyaşlarıyla bitecek" diyenler yanlış. Onlarca yıldır birden fazla diski birden çok sunucuya monte ediyoruz. Bir SAN (Depolama Alanı Ağı) ile çalıştıysanız, aynı cihazı genellikle FibreChannel SAN üzerinden birden çok düğüme bağlama yeteneği tamamen normaldir. Dolayısıyla, sanallaştırma / bulut sunucuları her yerde bulunmadan on yıl önce sunucuları çalıştıran herkes buna maruz kalıyor.
Yakında iki sistemin tam olarak aynı birime okuyabileceği ve yazabileceği kümelenmiş dosya sistemleri vardı. Bunun zaten tarihteki VAX ve Alpha VMS zamanıyla başladığına inanıyorum. Kümelenmiş dosya sistemleri, blokları doğrudan işleyebilmek için dağıtılmış bir karşılıklı dışlama şeması kullanır.
Aynı diski birden fazla düğüme monte etmenin avantajı hızdır ve tek hata noktalarını azaltmaktır.
Şimdi, kümelenmiş dosya sistemleri "tüketici" barındırma işinde çok popüler hale gelmedi, bu doğru. Ve karmaşıklar ve bazı tuzakları var. Ancak birden fazla hesaplama düğümüne bağlı bir diski kullanmak için kümelenmiş bir dosya sistemine bile ihtiyacınız yoktur. Salt okunur bir sürücü istiyorsanız ne olur? Kümelenmiş bir dosya sistemine bile ihtiyacınız yok! / Etc / fstab dosyasına sadece salt okunur olarak aynı fiziksel cihazı (ro) koydunuz. Daha sonra 2 veya 10 EC2 sunucusuna bağlanırsınız ve hepsi doğrudan bu cihazdan okuyabilir!
Hızla ölçeklenen çiftlikler kurarken bulut sunucuları dünyasında bunun için açık bir kullanım durumu vardır. Ana sistem diskinizi hazırlayabilir ve her sunucu için çok küçük bir önyükleme ve yapılandırma diski kullanabilirsiniz. Hatta hepsinin aynı önyükleme diskinden önyüklenmesini sağlayabilirsiniz ve okuma-yazma modundayken / okumadan hemen önce, 3 katmanlı bir Union-FS ekleyebilirsiniz:
Yani, evet soru çok mantıklıydı ve maalesef cevap (hala) "Hayır". Ve hiçbir NFS, sistem diskindeki tüm okuma etkinliklerini cezalandırdığı için bu kullanım durumu için mükemmel bir yedek değildir. Bununla birlikte, bir NFS sistem diskinden ağ önyüklemesi, yukarıda açıkladığım kullanım senaryosunu uygulamanın tek alternatifidir. Ne yazık ki, ağ önyükleme aracısını ve NFS'yi kurmak, aynı fiziksel blok cihaza erişmekten çok daha zordur.
Not: Bu yorum olarak kısa bir sürümünü göndermek isterdim, ama aptal 51 kredi puan eşiğinden dolayı yapamam, bu yüzden aynı temel "Hayır" ile bir cevap yazmak zorundayım ama bunun neden olduğunu belirtmek için haklı bir cevap almamış ilgili bir soru.
PPS: StackExchange'te iSCSI'den bahseden birini buldum. iSCSI bir şekilde NFS'ye benzer, ancak mantıksal olarak bir FibreChannel SAN'a benzer. Fiziksel engelleme cihazlarına erişir (ve paylaşırsınız). Önyükleme diski paylaşımını kolaylaştırır, böylece titiz olabilen bootd ağ önyüklemesini ayarlamanız gerekmez. Ancak daha sonra AWS'de ağ önyüklemesi de yok.
EBS daha önce belirli bir birime yalnızca tek bir EC2 örneğinin eklenmesine izin vermiş olsa da, en azından io1 birimleri için çoklu ekleme artık mümkün. Daha fazla bilgi için bu AWS blog yayınına bakın .
AWS'de birden çok sunucuda bir sürücüyü tamamen kullanabilirsiniz. Harici bir sürücü takmak ve EC2'de birden çok sunucuyla paylaşmak için sshfs kullanıyorum.
Tek bir sürücüyü birden çok sunucuya bağlamamın nedeni, tüm yedeklerimi yerel olarak çekmeden önce tek bir yere sahip olmaktır.