Techopedia Staff tarafından, 7 Aralık 2016
Paket servisi olan restoran: Sunucu Eric Kavanagh, Robin Bloor, Dez Blanchfield ve IDERA'dan Bert Scalzo ile kullanılabilirliği tartışıyor.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.
Eric Kavanagh: Bayanlar ve baylar, merhaba ve tekrar hoş geldiniz. Çarşamba günü saat dörtte Doğu Saati'dir ve bu günlerde veri dünyasındaysanız yaklaşık bir şey anlamına gelebilir: Hot Technologies için bir kez daha zamanı geldi! Evet kesinlikle.
Benim adım Eric Kavanagh, gösteriye ev sahipliği yapacağım. Neyin sıcak olduğunu, orada neler olduğunu, kuruluşta kullanılan harika şeyleri ve elbette, tüm bu alanda yaptığımız her şeyin temelinde veritabanı bulmak için tasarlanmıştır. Bu yüzden veritabanınızı koruma hakkında konuşacağız. Tam konu, “Veritabanınızı Koruyun: Yüksek Talep Verileri için Yüksek Kullanılabilirlik” dir. Yani, sizinki hakkında gerçekten bir slayt var. Ve benim hakkımda yeterince, Twitter'da beni vur, @eric_kavanagh.
İlk olarak, bu yıl sıcak, veriler sıcak, büyük veriler çok sıcak, ama yine de hala kenarda. Son teknoloji firmaların çoğu bugünlerde büyük veri kullanıyor, dünyadaki çoğu ekmek ve tereyağı organizasyonu, hala geleneksel verileri kullanıyorlar ve verileriniz yüksek talep görüyorsa, mevcut olduğundan emin olmak istersiniz çünkü sistemler çöktüğünde, veri erişilemediğinde, mutsuz müşteriler, mutsuz beklentiler elde ederseniz, müşteri karmaşası alırsınız, her türlü şeyden, iş ortaklarından vb. mutsuz olursunuz.
Bugün iş dünyasının en iyilerinden bazılarını öğreneceğiz - otuz yıldır çalışan veritabanı uzmanı Dr. Robin Bloor'dan haber alacağız. Uzun süredir bunu yapan Dez Blanchfield, ama gerçekten gençken başladı ve IDERA'dan Bert Scalzo, gerçekten de veritabanı siyah kuşak. Bu yüzden geride durmayın, millet, soru sorun - bu etkinliğin büyük kısmı sizin için değerlidir, iyi sorular sorduğunuzda ve iyi yanıtlar aldığınızda, bunları sohbet penceresi veya konsolunuzun Q ve A bileşeni aracılığıyla gönderin.
Ve bununla Robin Bloor'a teslim edeceğim - götürün.
Robin Bloor: Tamam, bunu tıklayayım ve hareket edip etmediğini göreyim - oluyor. Özellikle veritabanı hakkında konuşmayacağım. Biliyorum, biliyorsunuz, çünkü giriş, ilk tanıtım sunumunu yapıyorum, bu yüzden beklenen hizmet seviyeleri ve elbette kullanılabilirlik hakkında konuşacağım, bu da bugünün şovunun konusu olan anlaşma.
Ve soru şu, bilirsiniz, “Gerçekten, kullanılabilirlik nedir? Ve insanların günümüzde veri merkezlerini yönetme biçiminde hangi rolü oynuyor? ”Fark ettiğim bir şey - bunu 90'larda gerçekten fark ettim - bir sitede çalışıyordum ve kullanıcılar şikayet etmeye başladı, çünkü e-postaları 15 dakika.
İlginçti, çünkü CTO ya da BT'den sorumlu olan herkes aslında, o günlerde hizmet seviyelerini gerçekten belirledikleri ve 15 dakika boyunca e-postanın kimsenin hizmet seviyesini ihlal etmediği birkaç yerden biri vardı. . Aslında iki saat dışarı çıkmasına izin verildi. E-posta kullanılamadı, sadece sunucu dışarı olduğu için gönderip alamıyordunuz. Ve bu tür bir şey beni o zamandan beri ilerlediğimi fark ettiğim, her şeyin hızlandığını ve kullanıcıların beklentilerini de etkilediğini uyardı ve bu sizi insanların üç hizmet seviyesine sahip olabileceği duruma götürüyor, ancak çoğu zaman hizmet düzeyleri gerçekten ihlal edilmediğinde şikayet etmeye başlayacaktır.
Yani hizmet seviyelerinin tanımı, sadece bir - iyi vermek için, hizmet seviyeleri açısından tam olarak neden bahsettiğinize bağlı olabilir. BT sistemi veya BT uygulaması hakkında konuştuk. Normalde performans, kullanılabilirlik ve metrik olarak tanımlayın - başka bir deyişle, ölçemediğiniz sürece bir hizmet seviyesini gerçekten tanımlayamazsınız, bu nedenle normalde bir tür ölçüm söz konusudur ve normal olarak yanıt süreleri, belirli işlemler ve belirli bir süre boyunca sistemlerin mevcudiyeti ve yaklaşık 1994–1995 öncesinde, herhangi bir sistemin normal çalışma saatlerinden daha uzun süre kullanılabilir olması gerçekten nadirdi. O zaman diyelim ki sabah sekizden akşam altıya, normal bir açıklık vermek - ve insanlar sistemleri inşa ettiler ve bu şekilde ve yani - bence, özellikle veritabanıyla - veritabanını belirli bir şekilde ve toplu pencere küçülmeye başladı, bazı sistemlerde ve sonra diğer sistemlerde tekrar düşünme ihtiyacı ortaya çıktı ve daha sonra, daha önce bağımlı olmayan sistemler arasında bağımlılık yapmaya başlayan hizmetin veya mimarinin gelişini aldık her şeyi daha da kötüleştiriyor. Sistemlerin mevcudiyeti açısından sıkmayı aldık.
Demek istediğim, kullanılabilirlik hakkında konuşurken, yedekleme ve kurtarma içerir ve içerir - sadece bahsettiğimiz normal şartlarda kullanılabilirlik değil; bir uygulamanın başarısız olabileceği birçok farklı yol vardır. Bilirsiniz, donanım arızası alabilirsiniz veya veritabanı arızası alabilirsiniz, yazılım arızası alabilirsiniz ve bu türden bir sürü farklı tür vardır ve ortaya çıktığında iyileşebilmeniz gerekir ve bu nedenle geri dönmeniz gerekir. sistemleri. Bu nedenle, sistemi yedeklemenin bir şeması olmalı ve ayrıca, günümüzde birçok sitede, tüm bir binanın patlaması durumunda felaket kurtarma yeteneğine ihtiyacınız var. Ve burada bahsetmeye değer bir şey ve bir dakika içinde bu konuya değineceğim, ancak iş süreçleri, hizmet seviyelerine de sahipler ve gerçekte, iş sürecinin gerçekten iş için önemli olan hizmet seviyeleri var. BT sadece kendi payına düşeni yapmak zorunda.
BT hizmet seviyeleri normalde iş süreci hizmet düzeylerine yardımcıdır, ancak 15 yıl önce herhangi bir kuruluşun iyi tanımlanmış hizmet düzeylerine sahip olması gerçekten nadir olduğu gibi, kuruluşların iş süreçleri için iyi tanımlanmış hizmet düzeylerine sahip olması hala oldukça nadirdir. . Bu şimdi olan bir şey; uzun süredir devam eden bir şey değil.
Bu hızlanma ve zaman bariyerleri, sadece zaman bariyerlerinden bahsetmeye değer. Yavaş yavaş bir olay işleme dünyasına geçiyoruz ve bu nedenle yavaş yavaş gerçek zamanlı bir dünyaya geçiyoruz ve bu nedenle yavaş yavaş 24 x 7'lik bir gerekliliğe ulaşılabilirliğe geçiyoruz ve bu aslında birçok sistem için zor - bu başarılması zor. Ya çok pahalı, ya da bazı durumlarda sistemleri değiştirmeniz, hatta farklı bir veritabanına, hatta kullandığımız veritabanı yazılımının farklı bir sürümüne geçmeniz gerekebilir.
Ayrıca bu zaman bariyerleri - ve her fırsat bulduğumda bunlardan bahsetmek isterim - bunlar uygulamalarımızın karşılaştığı zaman bariyerleri; uygulamalar olabildiğince hızlı olmak isteyebilir, o zaman yazılım yazılımla konuşur. Bazı durumlarda gerçekten kabul edilebilir bir lisans yoktur, olabildiğince hızlı olmak istersiniz ve satınalma siparişi ile gelen kişinin birinden daha kötü bir fiyat aldığı piyasa durumları gibi iş koşullarındaki durumlar ve bu yüzden yazılım hızı gerçekten önemlidir.
Ama biliyorsunuz ki, aslında insanlarla - etkileşimde bulunduğunuzda - gerçekten talep edilebilecek en iyi tepki süresi saniyenin onda biri, çünkü bu bir insanın tepki süresiyle ilgilidir. Bundan daha hızlı gitmenize gerek yok çünkü bir insan zaten fark etmeyecek. 1.1 ve dört saniye arasında insanların normal olarak tolere edeceği bir bekleme süresi vardır, ancak yaklaşık dört saniye geçtikten sonra başka bir şey yapmaktan vazgeçerler ve bu nedenle gerçekten bir toplu iş faaliyetindesiniz.
Böylece, bir toplu iş davranışının mantıklı olduğu şeyler için belirli zaman çerçeveleri ile gün, hafta ve ayları görebilirsiniz ve bu nedenle bir olay işleme dünyasında bulunmuyorsunuz ve bu nedenle kullanılabilirliğin aslında ihtiyacınız olan şey açısından oldukça farklı olabileceğini görebilirsiniz. sağlayabilmek. Ancak etkinlik dünyasına girer girmez, 7/24 ulaşılabilirlik durumundasınız ve teknoloji değişimi daha hızlı ve daha hızlı ilerledikçe teknoloji değişikliği bir faktördür; sadece olduğu gibi kalır.
Bu karmaşıklık katmanlarıdır ve buna derinlemesine girmek istemiyorum, sadece, bilirsiniz, burada dikkate alınması gereken üç şey var. Altyapının hizmet seviyesi vardır, bu dikey eksendir ve sonra herhangi bir uygulamanın hizmet seviyesi vardır ve daha sonra bir iş hizmet seviyesi vardır ve bunlar birbirine bağımlıdır ve dikkate alınması gerekir aslında hizmet düzeylerinin karşılandığı duyarlı bir ortam oluşturmak istiyorsanız.
Daha sonra, aşağıda gösterilen veritabanları var, ancak sistem içinde herhangi bir şey yapabilirsiniz, kesintisiz yapılandırmaya sahip olduğunuzu biliyorsunuz, yani ne diyor: asla durmayacak. Sıcak bekleme durumuna sahipsiniz, burada bir şekilde elde etmenin farklı yolları var, ancak bir şekilde veya başka bir şekilde, bir veritabanı arızalanırsa, sıcak bekleme durumuna geçer ve çok az gecikme olur zaman açısından, kullanıcıların muhtemelen fark edeceği, ancak çok fazla fark etmeyeceği noktaya kadar.
Sıcak bekleme, veritabanı bekleme durumuna alınırken herkesin yardım masasını çaldığı ve yardım masasında orospular yaptığı 20 dakikalık geçişe daha çok benziyor. Sonra çok uzun bir zaman alabileceği bir yeniden başlatma durumu var. Herhangi bir uygulama veya verilen herhangi bir veritabanının, gerçekte neler olduğuna ve uygulamanın gereken hizmet düzeyinin gerçekte ne olduğuna bağlı olarak herhangi bir durumda olabileceğini belirtmek gerekir.
Bundan sadece karmaşıklık eğrisi hakkında bir noktaya değinmek istiyorum. Karmaşıklık düğümlerden ve bağlantılardan, bağımlılıklardan kaynaklanır. İçinde yaşadığımız dünyada, her şeye dahil olan düğümlerin ve bağlantıların sayısı büyümeye devam ediyor, bu nedenle bu tür bir amaca uygun eğriye koşuyorsunuz. Karmaşıklığın nasıl arttığına ve zaman boyutlarının nasıl küçüldüğüne bakabiliyorsanız, kullanılabilirlik seviyeleri için biliyorsunuz, zaman hedefleri var mı, muhtemelen azalıyor mu?
Ve doğal evrim bu yüzden en pahalı - en azından benim deneyimime göre - oluşturduğunuz en pahalı yapılandırmalardır. Öyle ya da böyle, bunu düşünen herhangi bir organizasyonun, sadece şu anda olanları değil, gelecekte ne olacağını da düşünmesi gerekiyor.
Belki de belirtmek istediğim son nokta, hizmet seviyelerinin yönetimi devam eden bir faaliyettir; bir projeniz olduğunu bildiğiniz bir şey değil, bunu yapıyorsunuz ve bitti. Değil, çünkü işler değişmeye devam ediyor. Bunu söyledikten sonra, topu Dez'e vereceğim.
Dez Blanchfield: Teşekkürler Robin. Açılış slaydını seviyorum. Filmi tekrar oynadık, sanırım film “Nemo'yu Bulmak”. Nemo'yu, oldukça sevimli olduğunu düşündüğüm dokuzlar şeklinde kullanılabilirliği aradınız. Takip etmek her zaman zor bir davranış. Çalışma süresi ve kullanılabilirliği ve yüksek performansı düşündüğümde, akla gelen ilk görüntü, çünkü yanardağların ve ekvatorun yakınında Solomon Adaları'nda büyüdüm, veri merkezimde patlayan bir yanardağ; her zaman aklımda olan bir şey var, bir şey patlarsa potansiyel olarak olabilecek şey bu. Bu güzel Mt bir resim. Sicilya'nın kuzeydoğu köşesi Etna, Catania'nın hemen yanında.
Buna yaklaşımım, sizinle bir görüşme yapmak ve C-suitlerden ve iş kolu başkanlarından düzenli olarak bir toplantı odasında yaptığım aynı seviyede birkaç görüşme yapmaktır. kuruluşunuzu ticari veya teknik anlamda neyin etkileyebileceği ve mühendislik türleri hakkında.
Düşünmeliyiz ve nasıl - bundan ne alacağımız ve daha sonra, özellikle otomasyon ve platformlar hakkında yüksek kullanılabilirlik ve çalışma süresi hakkında konuşurken bahsettiğimiz bazı zorlukları nasıl ele alacağımız.
Yani, başlangıçta ortaya koyduğumuz soru, veritabanı sistemleri ve veritabanı platformunun kullanılabilirliği hakkında konuştuğumuzda aslında ne demek istiyoruz? Robin'in gerçekte neye ihtiyaç duyduğumuzu ve istediğimizi gösteren hizmet seviyesi anlaşması yüklü haritalamasında bahsettiği gibi bir şeyi bir seviyeye ulaşmanın gerçek zorluğu hakkında konuşmak ne anlama geliyor?
Yani, bugünün gerçeği - ve aslında burada aklımda birkaç tepe gerçeklik var - bugün her şey etkili bir şekilde veritabanı odaklı. Bugün inşa edilmiş ve bir şeyler sadece dosyalarda saklanacak ya da bir tür düz dosya günlüğü olacak şekilde inşa edilmiş çok az sistem vardır; her zaman her şey veritabanına dayalıdır. Bunun bir sonucu olarak, bu veritabanlarının, bunlara bağlı farklı sistem ve uygulamaların ve araçların kullanılabilirliği hakkında düşünmeyi bırakmak ve sunmak, satmak veya tüketmek istediğimiz hizmetleri sunmak için onlara güvenmek zorundayız. . Ve çevresindeki tüm altyapı.
Aslında, o kadar ki, özellikle dijital yerliler veya bulut yerlileri, Uber ve Airbnb ve benzeri gibi ortaya çıkan bazı şirketler ve biraz daha eski PayPals'ın büyük veri kesintilerini düşündüğünüzde ve dünyanın eBay'leri - bu kuruluşların ölçeği ve büyüklüğü ancak modern veritabanı teknolojisi ve modern bulut altyapısı nedeniyle mümkündür. Bu olmadan, eklenen yetenek olmadan, kesinlikle var olmazlardı. EBay'e yalnızca 9:05 ile 9:25 arasında erişebileceğiniz bir senaryo düşünün, çünkü günün geri kalanında kullanılamıyordu çünkü bir iCloud veya yedekleme veya bunun gibi bir şey yapmaya çalışıyordu, çalıştı.
Dolayısıyla, günlük yaşamlarımızı düşündüğünüzde, perakende ve bankacılık, finans ve havayolları vb. Gibi başka önemli alanlar da var. Havacılık lojistiği, nakliye taşımacılığı gibi büyük sanayi grupları, bir bütün olarak hükümet var, ulusal güvenlik ve polis vb. Tüm bu endüstriler, tüm bu pazar segmentleri, tüm bu organlar, gruplar ortamlarının çalışır durumda olmasına bağlıdır.
Yani, bunu aklımızda tutarak, düşünmemiz gereken diğer uyarılara, sizi düşünmeye bırakmak istediğim diğer paketlere de sahibiz ve işte dünyamız şimdi “her zaman açık” diyorum. Kalıcı olarak bağlıyız ve bu düzenli olarak duyacağınız bir tema ve tekrar edip tekrarlayacağım. Artık tüm gün, her gün elimizde akıllı telefonlar var. Onları kapatmıyoruz, onları yatağın yanına koyarız, her zaman çalar saat olarak kullanırız, kamera olarak kullanırız ve fotoğraf çekeriz, bu fotoğrafları buluta taşırlar.
Daima açık, sürekli bağlantılı zihniyete sahipler. Aslında, kullanmayı sevdiğim bir cümle parası var ve şimdi her şeyi ölçtüğümüz, her şeyi izlediğimiz Fitbit neslini yaşıyoruz ve günlüğe kaydedilmesi gerekiyor ve bu bir yere gidecek.
Ayrıca sizi bırakacağım başka bir ifade daha var ve bu, her zaman saat dokuzda bir yerde. İçinde yaşadığımız 24/7/365 dünya. Dünya sürekli Güneş etrafında dönüyor ve bir noktada ve zamanla günün her saati saat dokuzda. Ve bu, insanların yataktan kalktığı ve bir şeyler yapmaya, bir şeyler satın almaya, bir şeyler kurmaya vb.
Yüksek kullanılabilirlik hakkında konuşurken ne demek istiyoruz? Detaylara dalmaya başlayana kadar çok açık görünüyor. Yani, “Tamam, yüksek kullanılabilirlik ne anlama geliyor?” Diye düşündüğümüzde biliyorsunuz. Gerçek şu ki, gümüş mermi yok. Robin'in kullanılabilirliği ve hizmet seviyesi anlaşmalarını ölçmek gibi bahsettiği bazı konularla ilgili olarak oldukça karmaşık bir kavramdır. Biz bu sorularım, çalışma zamanı mı? Bir dakika içinde gireceğim beş dokuz dediğimiz şeyler hakkında endişeleniyor muyuz? Kendimizi hizmet düzeyi sözleşmelerimizde neler olduğunu düşünüyor muyuz? Örneğin, hizmet düzeyi sözleşmelerinde, gecikmeler olduğu anlamına gelir, hizmet düzeyi sözleşmelerinin üç harfli kısaltması bugünlerde giderek daha kritik hale gelmiştir.
Bu şirket içi ve kendinden barındırılan tüm süreci üçüncü taraf veri merkezlerine ve dış kaynaklı yönetilen hizmetlere aktarırken ve şimdi bulut bulmaya çalışıyoruz. Ve gerçek şu ki, bulut hakkında konuştuğunuzda, bu sadece diğer insanların bilgisayarlarıdır. Bu, altyapıyı çalıştırmamanız, sistemleri çalıştırmamanız ve her zaman bulut çalıştırmamanız gerektiği anlamına gelir. Platform olarak kurulmuş altyapı yapıyorsunuz, bu nedenle satış gücü hizmetinde daha da önemli. Şimdi satış düşünün, örneğin, bu altyapıdan herhangi birine dokunmadığınızı biliyorsunuz, sadece bir web arayüzüne giriş yapıyorsunuz.
Bu nedenle, bulut dünyasında sahip olduğunuz tek mekanizma ve hizmet düzeyinde anlaşmalar olan herhangi bir formun dış kaynaklı altyapısı, sahip olduğunuz tek mekanizma budur ve insanlar kurulumunuzu karşılamıyorsa, ya da cezalar ve onlara ödediğiniz para miktarında azalma ya da sadece ödemezsiniz.
Yani, bu yüksek kullanılabilirliği nasıl yönetebileceğimizin tüm zorluğunu akla getiriyor. Altyapınız değilse kullanılabilirlik çalışma süresini nasıl yönetiriz - örneğin hepsi SLA ile ilgilidir. Altyapınızsa veya tasarım açısından başka birinin altyapısı olsa bile. Model bilimine yük dengeleme hakkında konuştuk, bir hataya dayanıklı tasarım patenti mi?
Mimarilerinizde aktif veya aktif bekleme modunu mu kullanıyorsunuz? Birden fazla sunucunuz, birden çok depolama platformunuz var mı? Bu depolama platformları nasıl çalışır? Birbirlerini kopyalarlar mı, birbirlerini aynalarlar mı? RAID mi kullanıyorsunuz? Yedek depolama için ne tür RAID kullanıyorsunuz? RAID'i disk düzeyinde mi çalıştırıyorsunuz? Model sürücüler ve model sistemler ve sürücüler arasında çoğaltan bir nesne depolama platformu mu kullanıyorsunuz? Sahip olduğunuz her küçük altyapı için N artı bir mi? Başka bir tane ekliyor musunuz ve aynı veri merkezinde mi yoksa başka bir veri merkezinde mi? Örneğin, tek bir satış noktasını hesaba katmayan bir tasarım patenti oluşturdunuz mu?
Tüm bu temel şeyler, şimdi basit kavramlar gibi geliyorlar, ancak bunların her birine girdiğinizde çok, çok ayrıntılı şeyler. Kullanılabilirlik hakkında konuştuğumuzda, her zaman dokuzlardan bahsediyoruz. Dokuzlarla ne demek istiyoruz? Hepimiz bunları duyduk, ama bir dakikalığına ne anlama geldiklerini ve neden önemli olduklarını düşünelim.
Yani, dokuzdan bahsediyoruz, bu da müsaitlik durumumuzun sadece yüzde 90'ı. Kulağa çok yüksek geldiğini biliyorum. Yani, 24 x 7 ile 365 arasında konuştuğumuzda, örneğin sadece bir yıla bakarsak, zamanın yüzde 90'ı olan dokuzda konuşurken, otuz altı buçuk günlük kesinti süresine izin verir. Bunu bir aydan fazla bir süre içinde tamamlayalım.
Şimdi her gün uğraştığımız herhangi bir işi düşünün - ister çevrimiçi bankacılık, eBay, PayPal veya ister LinkedIn, Twitter veya sadece genel bir perakendeci gibi sosyal medya platformları olsun - diyelim ki güneşli bir şekilde ABD'ye gelmek için bir uçuş rezervasyonu yapmak istedim Avustralya, bir hafta içinde Amerika'ya gelmek istersem, en sevdiğim havayolu şirketi otuz altı buçuk gün boyunca düştüyse mutlu olurdum çünkü servis sağlayıcıları, "Bak, zamanın yüzde 90'ı için hazırız "? Tabii ki yapmazdım.
Bu modeli yukarı çıkardığınızda, iki dokuz: yüzde 99. Bu 3.65 gün, yılda kabaca üç buçuk gün kesinti olur. Bu büyük bir anlaşma mı? Eğer Kara Cuma çalıştırıyorsanız ve özel bir satış yapıyorsanız ve insanlar sadece bu birkaç gün boyunca satın alabilirler.
Üç dokuz yılda 8, 7 saat kadar az olur, ancak yılda 8, 7 saat bile, zamanımızın ardışık sekiz saati durur. Bankacılık ve finansta, sağlıkta - eğer bir hastane ise, hayat pahalıya mal olabilir. Tırmanırken, dört dokuz 52 dakika, beş dokuz beş dakika ve altı dokuz temel olarak 30 saniyedir. Altı dokuz son derece yüksektir ve bu merdiveni yukarı kaldırırken, bu Noel dokuz ağacına tırmanırken, ne kadar fazla dokuz yükselirseniz, tasarım, çevre ve platform o kadar zor olur. Bu hizmeti sunmak daha zordur ve yedeklemelerin çalıştırılması, yönetim, yama, herhangi bir kesinti için bakım pencereleri için gereken zaman miktarındaki azalmayı düşünüyorsanız - önemsiz olmayan tüm zorluklar - ve hepsi etkin bir şekilde kesintilerin yüzdelerine iniyor.
Burada iletmek istediğim anahtar, daha önce bahsettiğim gibi gümüş mermi yok. Kullanılabilirlik söz konusu olduğunda, "tek beden herkese uyar" diye bir şey yoktur. Kilit endüstrilere uyan özel bir tasarım patentiniz olabilir. Aynı zorluklar tüm bankalar tarafından karşılanmaktadır. Bazıları perakende bankalar, bazıları premium bankalar olabilir. Bazı bankalar ticaret ve yatırıma, varlık yönetimine odaklanıyor olabilir. Bazıları tamamen tüketici olabilir. Bazıları sadece internet yerleştirme olabilir ve hatta söz sahibi olmayabilir ve sadece nakit dağıtırken ATM'lerle ilgilenebilir. Bu senaryolarda, bankacılık ve servet yönetimi ve finansal hizmetler endüstrisinde bir bütün olarak bile, her biri için kullanılabilirlik söz konusu olduğunda kendi özel lezzetleri veya ihtiyaçları olan şeyleri vardır.
Bu yüzden, sade İngilizcede mevcudiyet hakkında düşündüğümüzde, mevcudiyet ve yüksek mevcudiyet arasındaki karışım - bunların aynı şey olduğunu düşünüyoruz, ama aslında tebeşir ve peynir. Kullanılabilirlik, bir sunucunun veya işlemin normal veya genel olarak işlevlerine bağlı olarak kullanılmasına bağlı olan bir zaman ölçüsü olan düz İngilizce'ye koydum. Bu sadece mevcut olup olmadığını nasıl tanımladığımız anlamına gelir. Kullanılabilirlik hakkında konuştuğumuzda, bu altyapının güvenliğini korumak için yüksek kullanılabilirliğe karşı, genellikle “mevcut bir formda sağlıyorum” düşünme tuzağına düşüyoruz.
Yüksek düzeyde kullanılabilirlik, başka bir deyişle, düz İngilizce olarak, özellikle yılın neredeyse her zaman –24/7/365 gün - bir çeşit sonuç ve kullanılabilirlik uyguladığınız veya elde ettiğiniz tasarımdır. Dokuzlar. Her zaman yüzde 100 demek değildir. Herhangi bir ortamda gerçek bir dünyada yüzde yüz teknik olarak mümkün değildir. Üzerinde bir veritabanı bulunan bir işletim sistemindeki bir sunucu için çok zordur ve bir platform çalışır ve bir uygulamada onu teslim edebilir ve yüzde 100 çalışmasını bekleyebilirsiniz. Sonra tasarımları düşünmeye başlarız. Fazlalıklarımız var mı, çoğaltmak için birden fazla slaytımız var mı? Daha sonra düz İngilizce'ye koyduğunuzda, kullanılabilirlik konusunun yüksek kullanılabilirliğe karşı ne kadar farklı olduğu ilginçtir.
Hizmetinizin çalışma sürelerini koruma konusunda kullanılabilirliği artırma zorluğuna tırmanmaya başladığınızda bunun nasıl göründüğüne dair bir fikir vermek için gerçekten basit bir grafik formda koyacağımı düşündüm. Sol alt köşede tek bir dokuz var. Genel olarak bahsettiğimiz beş dokuzu belirledim. Altı dokuz parça biraz çirkin. Sol alt köşede yaklaşık beş dokuz, kabaca bu kesinti 35 gün hakkında konuştuğumuzda, bunu sağlamaya çalıştığınız düşük maliyetli ve düşük karmaşıklığa sahip bir ortamdır, çünkü başarısız olabilecek birkaç şeyiniz var ve yine de hizmet düzeyi sözleşmelerinizi karşılar.
Ancak alttan soldan sağa doğru ilerledikçe ve resimde daha fazla dokuzun olduğu noktaya geldiğinizde, sistemlerin ve platformların çoğaltılması hakkında düşünmeye başladığınız senaryoları elde edersiniz. Altyapının çeşitli bölümlerinin kümelenmesini ve sanallaştırılmasını düşünmelisiniz. Bu kümelerin coğrafi konumlarını, birden çok veri merkezi sitesini düşünmeniz ve hedeflediğiniz endüstri ve pazar segmentinin türünü düşünmeniz gerekir. Öyleyse ne tür bir hizmet seviyesine ulaşmanız gerekiyor? Hangi hizmet sunumunu arıyorsunuz? İletişimi anlatan gerçek zamanlı kart tabanlı hizmetlerdir. Askerlik mi? Böylece bu grafik sol alttan sağa doğru gider ve bu eğriden geçtikçe maliyet ve karmaşıklık artar. Daha karmaşık ve daha zorlu ortamlar elde ettikçe, daha fazla dokuza ihtiyacınız olacak.
Örneğin bu grafik çok benzer bir şey yapar: maliyet bileşeni ile istenen kullanılabilirlik bileşeni arasındaki hikayeyi açıklar. Bu nedenle, sol üst köşede yüksek kullanılabilirliğe sahip karmaşık sistemleri ve bu kullanılabilirliğin düşmesi durumunda ortaya çıkan maliyeti sıfır kesinti süresinde kullanılabilirliğe sahip olma avantajına göre eşleştiriyoruz. Örneğin, sol tarafta bir şeylerin düştüğü bir ortam varsa, mali kayıplara uğrayabiliriz. Ticari iş stratejisi düzeyinde çıkarımlar olabilecek yasal çıkarımlarımız var.
Bir hizmet avantajına sahip olmakla ilgili her türlü potansiyel, sanırım hatta ahlaki sorunlar da var. Eğer bir sağlık endüstrisiyse ve bir kesintinin maliyetini, müşterileri etkilemeyi, müşteri memnuniyetini azaltmayı, personel verimliliğini, kullanıcı verimliliğini vb. Geçmeye başlarlarsa, son derece karmaşık, son derece bağımlı tasarım yapmayı düşünürsek bunlar etkilenir., kesinti riski ve dolayısıyla kayıp riski bulunan yüksek riskli ortam.
Sağ tarafta, tasarıma yüksek maliyet ve planlamaya yatırım yaparsak akıllı uygulamaya yatırım yaptığımız bir senaryo hedeflemeye çalışıyoruz. İnsanlara beceri ve kaynak sağlamaya yatırım yapıyoruz ve ağ ve saygı duyulan operasyonel çevre ile donanım ve yazılımları çok önemsiyoruz. Yüksek kullanılabilirlik elde ediyoruz, ancak yüksek bir maliyetle geliyor. Böylece, ortada, geçtikleri yerde optimum pozisyonun sallanan sihirli sarkaç noktası, biraz daha düşük maliyete sahip olduğumuz ve sadece dokuz seviyeler ile sürekli kullanılabilirlik olan yüksek kullanılabilirlik arasında sallanan artan kullanılabilirlik ve bu bir aradığımız hizmet düzeyini elde etmek için ne kadar para yatırmaya hazır olduğunuzda olduğu gibi, buluşmamız için sürekli zorluk mu yaşıyorsunuz?
Ayrıca üzerinde ayrıntıya girmeyeceğim bir konu var, ama sadece bunu alıp düşünmeni istiyorum. Tasarımınızdaki başarısızlık arasındaki ortalama süre ile kurtarılacak ortalama süre arasındaki fark. Başka bir deyişle, daha kaliteli altyapı, daha kaliteli tasarım, daha kaliteli donanım ve yazılım ve daha kaliteli vasıflı personel ve kaynaklara mühendislik işleri yapmak ve başarısızlık arasındaki ortalama süreyi azaltmak, aksine mola bulmak için geçen ortalama süre altyapıya, kaynaklara ve tasarıma ve kör patentlere daha az yatırım yapmak, yüksek kurtarma kabiliyeti? Başka bir deyişle, bir şey bozulursa, takmak için çok şey var. Birinin dizüstü bilgisayarı varsa ve ölürse, yedek bir tane var. Onlara veriyorsunuz ve 30 saniye içinde giriş yapıyorlar. Bunlar direğin çok farklı uçları. En iyisi başarısızlıktan kaçınmak için yüksek maliyet ve yüksek yatırımla mühendislik yaptığınızı ve altta ise “Başarısızlığın geleceğini kabul edeceğim, bu yüzden bunun etrafında mühendislik yapacağım ve başarısızlığa hazır olacağım ve çabucak iyileşin. ”
Daha önce de belirttiğim gibi, “Kullanılabilirliğim uygunluğunuz değil” diyebileceğim yer. Yani veritabanı ortamları ve altyapıyı destekleme, veritabanınızı çalıştırma ve bunu koruma ve yüksek kullanılabilirlik sağlama konusunda gerçekten tek elden bir dükkan yok . Herkesin kendi ihtiyaçları ve istekleri vardır. Bu yüzden kendinize, size bırakacağım bu temel soruları sormalısınız ve bu: Kuruluşunuz neyi karşılayabilir? Sadece dolar ve sentlerden bahsetmiyorum. Bir kuruluş olarak, kullanılabilirlik düzeyinin sağlayabileceği kadar kaynak, zaman ve çabadan vb. Neler yapabileceğinizden bahsediyorum. Ayrıca, işletmeniz neleri destekleyebilir? Yani, mevcut yetenekler, mevcut beceriler, mevcut altyapı, mevcut finansman artırabilir. Yani gerçekten karşılayabileceğiniz şeyler ile destekleyebileceğiniz şeyler arasında dengelemek ilginç bir denge.
Ayrıca, kendinize şu soruları sormanız gerekir: Şirket içinde hangi becerilere ve teknolojiye sahipsiniz? Bu zorluğun bir kısmını dışarıdan temin edebilir misiniz? Daha sonra işleri buluta taşıyabilir misiniz? Altyapı hizmetini yazılım hizmetinden ayrı olarak aldıysanız, yığının daha üstüne çıktıkça bu yığının dışında kalırsınız. Peki, platformlara ve hizmete daha fazla yatırım yapmalı ve altyapı parçası hakkında endişelenmemeli misiniz yoksa yazılıma platform hakkında endişelenmenize gerek kalmayacağından bir hizmet teklifi olarak mı bakmalısınız?
Ne tür bir pazar ve tüketici veya müşteriye hizmet veriyorsunuz? Yani, eğer bir telekom iseniz ve birisinin telefonu alması gerekiyorsa ve her zaman çevir sesi alırsanız, bu Pazartesi ile Cuma günleri arasında dokuzdan beşe kadar küçük bir perakende mağazası açmak ve Bir köşe mağaza berber gibi öğle vakti. Bu yüzden bunun nasıl çalıştığını ve bunun kuruluşunuz için ne anlama geldiğini, neler sağlayabilmeniz gerektiğini çok uzun ve çok düşünmelisiniz.
Ve sonra binadakiler, dışarıdan barındırılanlar ve potansiyel olarak bulutta olanlar arasında dengeleme yapın. Daha önce de söylediğim gibi, bu da zamanın zorluklarından geliyor. Bu nedenle, IDERA'daki arkadaşlarımıza bu şeyleri nasıl ele aldıklarını anlatmak için sabırsızlandığım ve bu istenen ve gerekli kullanılabilirliğin performansla eşleştirilmesi ile işinizin neye ihtiyacı olduğu ve neyin neye ihtiyacı olduğu gibi son bir soruya bırakıldık. pazarınızın ve tüketicilerinizin ihtiyacı var.
Ve gerçek şu ki bu hiç de feat. Bunlar hakkında düşünmek zaman, çaba ve para gerektirecek. Ve bu süreçlerin bazılarını otomatikleştirmek ve insanlara hayatlarını sadece daha iyi değil aynı zamanda mümkün kılmak için doğru araçları ve doğru sistemleri sağlamak için insanlara ve becerilere yatırım yapma ve yazılım ve araçlara yatırım yapma, çünkü çok büyük ölçekli ortamları izleme ve koruma ve bu büyük ölçekli ortamları yönetmek genellikle bireysel insan yeteneklerinin ötesindedir.
Bunu göz önünde bulundurarak, umarım IDERA'daki arkadaşlarımızın platformları ve araçları hakkında konuşmak için harika bir konuşma ortamı hazırladım ve sonunda bazı harika sorular sormayı dört gözle bekliyorum. Ve ben geçeceğim.
Dr. Robin Bloor: Tamam. Bert, sadece anahtarlarý verdim, götürün.
Bert Scalzo: Teşekkürler! Teşekkürler, Dez ve Robin. Verileriniz için yüksek kullanılabilirlik konusuna devam edeceğim. Ve aslında Dez'in bahsettiği şeylerin çoğunu kullanacağım. Yani, seçimler, dokuzlar, değiş tokuşlar, karşılanabilirlik. Bunu daha çok veritabanı yöneticisine ya da siperlere daha yakın birine, nasıl bakarlar diye koyacağım. Nasıl mimarlardı? Ve bu seçimlerin ne anlama geldiği.
Şimdi, veritabanı agnostik olmaya çalışacağım. Örneğin, Oracle'a özgü veya SQL Server'a özel bir çözüm çizmeyeceğim, ancak diyelim ki, tüm veritabanı satıcılarının sunduğu genel bir mimari, bu satırlar boyunca bir şeyler çizeceğim. Hepsi farklı isimlerle adlandırıyorlar, ancak bu ortak yönünüz olan bir tür seçim ve buna hem iş hem de teknoloji perspektifinden ve bunun iş gereksinimleriyle nasıl ilişkili olduğundan bakmak istiyorum.
Ve en temel sözde yüksek kullanılabilirlik çözümünden başlamak istiyorum, depolama düzeyi çözümlerinde, sanallaştırma düzeyi çözümlerinde, veritabanı düzeyi çözümlerinde sahip olduğunuz seçeneklerle. Ve sonra size tüm seçeneklerin bulutta da mevcut olduğu gerçeğini tanıtmak istiyorum.
Yani, yine, oldukça agnostik veritabanı kalmaya çalışacağım. Şimdi konuşacağım şeylerin çoğunun Oracle, SQL Server, MySQL, PostgreSQL'de bulunduğunu biliyorum. Ayrıca, düşünebileceğiniz ek mimariler verecek araçlar yapan bazı üçüncü taraf satıcılar da vardır. Ve Dez'in dediği gibi, hiç kimse en iyi çözüm değildir; hepsi bağlıdır. Ama bakacağımız şeyde evrensel bir gerçek var, daha hareketli parçalar olacak, bu yüzden daha karmaşık ve dolayısıyla daha maliyetli olacak.
Yani, hepimiz verilerin önemli bir varlık olduğunu biliyoruz. Ve herkes verilere hızlı erişimin her zaman iyi olduğunu bilir. Ancak, verilere güvenilir erişim önemlidir. Dokuz örneğiyle konuşurken, gerçekten 36½ günlük kesinti süresine sahip olabilir misiniz? Verilerin her zaman kullanılabilir olması kritik önem taşır. Bu nedenle, kesinti süresi, hem gelir kaybı açısından, hem de daha da önemlisi, kayıp müşterilerde veya müşteri iyi niyetinin kaybı açısından bir servete mal olabilir. Size iyi bir örnek vereceğim; alışveriş yaptığım belirli bir web sitesi yavaşsa, benzer öğeleri benzer web sitelerinde yavaş web sitelerine sahip olmayan yeni bir web sitesi bulmaya çalışabilirim. Ve bu sadece müşterinin kaybı değil, müşterinin size karşı olan iyi niyetidir.
Şimdi, donanım bugünlerde çok daha ucuz, bu nedenle yüksek kullanılabilirlik için giderek daha fazla talep var. Ve yine, buna baktığımızda bizi buluta yönlendireceğim. Ve çeşitli seviyelerden tekliflerimiz var: depolama satıcıları, veritabanı satıcıları, sanallaştırma satıcıları ve şimdi de bulut satıcıları. Ve böylece, bulutta gerçekten ilginç olan şey, bu mimarilerin bulutta oluşturabileceğiniz tüm bu harika resimlerini çizdikten sonra, çoğu zaman kontrol ettiğiniz bazı onay kutuları. “Coğrafi bölgeler arasında çoğaltma istiyorum” diyorsunuz. Onay kutusu. “Önemli donanım bileşenlerinin çoğaltılmasını istiyorum.” Onay kutusu. Ve böylece, resimleri anlarsanız, bazen bulutta, aklınızdaki resmi oluşturmak için sadece birkaç kutuyu işaretler.
Şimdi, kilit nokta, yüksek kullanılabilirlik için iş gereksinimleri nelerdir? Örneğin, yalnızca tek bir sitedeki başarısızlık konusunda endişelenmem mi gerekiyor yoksa birden fazla sitede mi bulunmam gerekiyor? Başka bir deyişle, bir bilgi işlem merkezim olabilir ve bu merkezin çevrimdışı olup olmayacağı umurumda değil mi? Birden fazla sitede genişleyen bir iş gereksinimi duymuyorum. Bu bir iş sorusu. İşletmenin bu sorunun yanıtlarını nasıl algıladığını bilmek önemlidir, çünkü bu genellikle bütçenizi tanımlar.
Şimdi, arıza koruma seviyesine de bakmak istiyorsunuz. Elektrik kesintisi olabilir mi? Bir bileşen arızası olabilir mi? Bir NIC veya HBA gibi kötüleşir, bir ana bilgisayar veri yolu adaptörü. Kötü giden bir sabit disk mi? Depolama dolabı arızası mı? Bir bilgisayar hatası mı? Veya bazı durumlarda site arızası mıdır? Bazı durumlarda site arızası olabilir, çünkü sitenin kendisi çevrimdışıdır. Başka bir durumda, sitenin önemli bir kısmı çevrimdışı olabilir, ancak perspektifinize göre tüm site budur.
Ve sonra, Dez'in bahsettiği gibi, operasyonları sürdürme zamanının beklentisi nedir? Bu bir iş sorusu. İşletme, iki dakika içinde operasyonlara devam edebilmeniz gerektiğini söylüyorsa, açıkçası, bu çalışacağınızı göstereceğim bazı resimler tanımlanacak ve bazıları sizin seçenekleriniz olmayacak seçebilmek.
Ve yüksek kullanılabilirlik sırasında ortaya çıkan bir başka soru, ama çoğu zaman insanlar sormayı unutuyor, "Hey, iş, bir işlemin ortasındayken bir şey olursa, sistemin yeniden başlatılması üzerine ne kaybedebilirim? " Diğer bir deyişle, sistemi iki dakika içinde geri getirebilirsem ve diyelim ki uçuşta olan işlemlerin 10 saniyesinden fazlasını kaybedemezim, bu kabul edilebilir bir iş mi? Ve yine, bu işin bunun için ne harcamak istediğini tanımlayacak ve daha sonra, size hangi resimleri göstereceğim ya da uygulanmadığımı göstereceğim.
Öyleyse, en temel sözde yüksek kullanılabilirlik çözümü ile başlayalım. Bu gerçekten yüksek kullanılabilirlik değil, ancak bununla başlamak istiyorum, çünkü insanların doğru düşünmesini sağlıyor. Bir sunucum ve bir depolama dizim varsa, genellikle birden çok NIC, ağ arabirim kartı, bu sunucuya koyacağım ve bir NIC başarısız olursa, hala hazırım. Aynı şeyi ana bilgisayar veri yolu adaptörlerimle yapacağım, farklı anahtarlar üzerinden çoklu yol kullanacağım, böylece depolamaya ulaşmak için birden fazla yolum olacak. Evrensel bir güç kaynağım var ve depolama dizimin içinde tekrarlayan denetleyicilerim var ve belki de disklerimle RAID 10 gibi bir şey yaptım. Başka bir deyişle, bu resimde birden fazla düzeyde tek bileşenli arızayı önledim. Bu yüzden, NIC, HBA, kontrolör veya anahtarla bağlı değilim.
Ancak fark ederseniz, sunucu kırmızı ve depolama dizisi kırmızıdır. Hala iki alan var, eğer başarısız olursa, sunucum giderse, ölüyüm, eğer depolama dizisi dolabım giderse, ölüyorum. Yani, bu gerçekten yüksek kullanılabilirlik olmasa da, resme bakıp bakmaya ve "Kırmızı olmayan bir resim istiyorum" demeye başlar. Ve bu doğru resme dikkat çekmek için bu resimlerin amacı bu.
Yani, gerçekleşecek ilk şey, bir DBA olarak, her zaman yüksek kullanılabilirlikli çözümü bir veritabanı uygulaması olarak koymak isteyebilirim, ancak bir depolama çözümü olarak yapılabileceği mevcut olabilir veya depolama düzeyi çoğaltma olabileceğini unutmayın. Solda depolama sanallaştırmam var. Neler oluyor, disklerim için iki farklı saklama dolabında RAID 0 var, ancak iki farklı saklama dolabında RAID 1 var. Başka bir deyişle, aslında bir saklama dolabında arıza yapabilirim ve ölmedim. Yani, önceki resimden daha iyi, çünkü önceki resimde - hem sunucuda kırmızı hem de depolama dizisinde kırmızı olduğunu hatırlayın - ve şimdi küçük bir gelişme yaptık, artık depolama düzeyinde kırmızıya sahip değiliz, kullandım - depolama sanallaştırma bu sorunu çözdü.
Şimdi, bunu yapabilmenin başka bir yolu - ve tüm satıcılar bunu sağlamaz - depolama düzeyinde çoğaltma yapabilmenizdir. Ben veritabanı çoğaltma konuşmuyorum, aslında depolama için blok I / O çoğaltma hakkında konuşuyorum. Ve bu depolama düzeyinde yapılabilir. Ve tekrar, şimdi sağ tarafta, alttan kırmızıyı çıkardığım başka bir resim var, çünkü depolama çoğaltması kullanıyorum.
Ve bu, mevcut olan veya bulunmayan başka bir resim. Ve bunu yönetecek kişi veritabanı yöneticiniz yerine depolama yöneticiniz olabilir. Bunu gündeme getirmeyi seviyorum, çünkü bazen insanlar "Ah! Yüksek kullanılabilirlik, bu sorunu ele alan DBA olmalı" diye düşünüyor. Bu her zaman doğru değildir; bu durumda depolama yöneticisi olabilir.
Şimdi, sunucu sanallaştırmasını olası bir çözüm olarak yapabiliriz. Şimdi hatırlarsanız, ilk resimde sunucuda kırmızı ve depolama dizisinde kırmızı vardı. Bu durumda, sanallaştırmayı kullanarak yer değiştirebilirim ve bazı durumlarda yer değiştirme bir tür sıcak yer değiştirme olabilir ve bazı durumlarda aslında sıcak bir yer değiştirme bile olabilir. Bazı sanallaştırma veya hipervizörler, sanal makineyi uçuş sırasında taşıma yeteneği sağlar. Ve bazı veritabanları uçuşta bu hareketi kolayca kabul edecektir. Şimdi, yine, tüm hipervizörler bunu sağlamaz, ancak bu olası bir çözüm düzeyidir. Şimdi, en iyi sunucuları artık kırmızı yapmadım, ama yine de paylaşılan depolama dizisine sahibim ve ne olduğunu tahmin ediyorum, bu çözüm veritabanı yöneticisi ile sanallaştırma yöneticisi arasında ortak bir çaba olabilir. Ya da bu hipervizörde ve bu veritabanında hangi yer değiştirme seviyesinin desteklendiğine bağlı olarak sadece sanallaştırma yöneticisi bile olabilir.
Merak ediyorsanız, “Vay canına, bu yer değiştirme ile ne anlama geliyor? Bana özel bir örnek verin. ”Örneğin, sanal makinenizi bir ana bilgisayardan diğerine taşımak ve kesinti olmadan bunu yapmak için VMotion'ı kullanabileceğiniz VM'de. Şimdi, önceki fotoğrafta hala biraz kırmızı var. Depolamayı hala tek bir hata noktası olarak gördüm. Ve bir sonraki çözüme geçelim, yani depolama ve sunucu sanallaştırmasını birleştirmeme izin verin.
Şimdi, bu durumda, yine, bu çözümü inşa eden depolama yöneticisi ve sanallaştırma yöneticisi olabilir ve şimdi bak: İçinde kırmızı olmayan bir resim var. Sanal makineyi veya çalışan uygulamayı veya veritabanını bir sunucudan diğerine taşıyabildiğim için yüksek kullanılabilirliğe sahibim ve iki ayrı depolama dizisinde RAID 1 yaparak depolama dizimde sanallaştırma var. Anahtarlarım ve HBA'larım çok yollu.
Şimdi bir HA sistemi kurdum ve bunu öncelikle veritabanı düzeyinde yapmadım. Başka bir deyişle, aynı şeyi başarmak için başka teknolojiler kullandım. Yani, bu bir çözüm. Sonra paylaşılan depolama alanı ölçeklenebilir kümesine giriyoruz. Gerçekten bir HA çözümü değil, ama yine de resim için göstermeyi seviyorum.
Ve burada olan, bir veritabanını çalıştıran iki sunucumuz olması ve bir veritabanı olarak kabul edilmesidir. İki ayrı veritabanı değil; bir efendi ve bir köle ya da sıcak ve soğuk veya aktif ve bekleme gibi değil. Bu, bu düğümlerin her ikisi de bir mantıksal veritabanı sunmak için birlikte çalışır. Ve böylece, belirli bir düğüm başarısız olursa, hala ayaktasınız. Bu nedenle, sizi sunucu düzeyinde hatalardan korur ve bunu temelde düğüm kaynaklarını parçalayarak yaparsanız yaparsınız, ancak yine de disk için en altta tek hata noktanız var. Bu nedenle, bu paylaşılan bir depolama ölçeklenebilir kümesidir ve Oracle bu Gerçek Uygulama Kümesi'ni veya RAC'yi çağırır.
Şimdi başka bir çözüm, paylaşılan depolama yük devretme kümesi kullanmaktır. Solda aktif bir düğüm var, sağda pasif bir düğüm var, arada bir kalp atışı var. Paylaşılan bir depolama dizim var ve bu çok önemli; buna sahip olmalısın. Ve temel olarak, aktif düğüm problemlerle karşılaşırsa, pasif düğüm devralabilir. Bununla ilgili lisans sorunları var. Bazı veritabanı satıcıları, pasif düğümü belirli bir süre için lisansı daha düşük olanlara sahip olmanızı sağlar. Diğer durumlarda, tam bir lisansa sahip olmanız gerekir. Her şey veritabanı satıcınıza bağlıdır. Ama hepsi bu tür resmi destekliyor, yani bir düğüm aşağı inerse, diğer düğüm devralabilir.
Ve tipik olarak, bu, aktif düğümden pasif düğüme gittiğinizde, muhtemelen, çoğu veritabanında - hepsi değil - bazılarını kaybedeceğiniz senaryolardan biridir. uçuş işlemleri. Sonra veritabanı yöneticisinin gerçekten neye bakabileceğini ele alıyoruz, ki bu veritabanı çoğaltmasıdır ve veritabanı çoğaltması yapmanın iki farklı yolu vardır.
Fiziksel çoğaltma var ve önemli olan, bu resmin ortasında yeşil yıldızla görebilirsiniz, çoğaltma, veritabanı tarafından yapılıyor, ancak depolama seviyesi sanallaştırma gibi, blokta yapılıyor seviyesi. Böylece, gerçek blok I / O'larını aktif düğümden salt okunur veya pasif düğüme tekrarlıyoruz. Ve bu fiziksel kopya olarak kabul edilir.
Şimdi, bir sonraki slayda gitmeme izin verin, çünkü neredeyse aynı ve mantıksal çoğaltma ve resimde değişen tek şey ortada, blok G / Ç'yi göndermek yerine, aslında günlüğü gönderiyoruz içinde SQL komutları bulunan dosyalar. Başka bir deyişle, çoğalttığımız şey fiziksel I / O değil, fiziksel I / O'ya neden olan komutlardır.
Bu nedenle, buna genellikle günlük gönderim veya günlük tabanlı çoğaltma denir. Bazı veritabanı satıcıları bunu size yerel olarak verir. Diğer veritabanı satıcıları bunu sunmayabilir, ancak daha sonra üçüncü taraf satıcılar bunu sunar ve bu çok popüler bir HA çözümüdür ve tam bir çözüm olarak kabul edilir. Ancak bu çözüm öncelikle DBA'nın sorumluluğundadır.
Bunu başarmak için sanallaştırma kullanmıyorum. Yapabilirdim, ama buna bağımlı değilim. Ve depolama sanallaştırmasını kullanmıyorum. Yine yapabilirdim, ama buna bağımlı değilim. Ama veritabanı birincil sürüş özelliği olan bir çözüm inşa ediyorum. Yani, bu mantıklı bir kopya.
Artık, veritabanı ve depolama sanallaştırmasını birleştirmek de mümkün. Veri merkezimde, diyelim ki, soldaki mavi renkte, depolama için sanallaştırma yapabilirdim, böylece belirli bir depolama dizisinin başarısız olmamasına neden olabilirim. Ancak bir veri merkezinden diğerine veritabanı düzeyinde günlük tabanlı veya mantıksal çoğaltma yapıyor olabilirim, böylece komutlar da veri merkezinde yürütülür, G / Ç ile sonuçlanır, ancak aynı G / Ç ile sonuçlanmaz, çünkü ' m depolama çözümü veya veritabanı tarafından blok I / O üzerinden gönderme değil, ancak günlükleri ve bu nedenle SQL komutları gönderiyorum.
Ve bu, bu çok büyük kuruluşlar için çok yaygın bir resim. Ve burada bu resmi seviyorum çünkü bunu Oracle gibi bir veritabanı kullanarak öncül olarak ayarlamak zorunda kalırsam, bunu yapabilirim; oldukça fazla iş, oldukça karmaşık, çok sayıda hareketli parça var. Bunu bulutta yaparsam tam anlamıyla söyleyebilirim, onay kutusu, iki coğrafi bölge istiyorum, bölgelerin farklı kıtalarda ayrılmasını istiyorum, belirli bir coğrafi bölgede depolama düzeyinde sanallaştırma istiyorum. Sanallaştırma türü ayırma veya yüksek kullanılabilirlik tanımı yapma yeteneğini istediğimi bile söyleyebilirim ve yine başka bir onay kutusu.
Ve bulutta sevdiğim diğer bir şey, sık sık "yama ile uğraşmak istemiyorum, sadece yama yap" demek için başka bir onay kutusu var, bilirsiniz, sadece arkasında yaptığınız her şeyin iş akışında çalışın sahneler, beni her zaman yamalı tut. Ve böylece, bu resimlerin bazıları çok karmaşık hale gelse ve yerinde yapmak çok zor olsa da, aslında bulutta yapmak oldukça kolay hale geliyor.
İlginç olan şu ki, tüm onay kutularını kontrol etmek kolay, ama tahmin edin, aylık olarak daha fazla paraya mal oluyor. Çünkü iki veri merkezi işletiyorsanız, bilirsiniz, bulutta kullandığınız iki veri merkeziniz vardır, sadece bir tane kullandığınızdan daha fazla ödeme yaparsınız. Aynı şekilde, depolama düzeyini veya sanallaştırma yüksek kullanılabilirliğini ek bir katman olarak yapıyorsanız, yine ek maliyetler olabilir.
Bu nedenle, sitede yapmak zor olsa da ve onu düşünebiliyorsanız, bulutta yapmak çok kolay olsa da, düşünmeyi düşünebilirsiniz. Yani, her zaman resmin nasıl göründüğünü ve inşa ettiğiniz resim için maliyet sonuçlarının ne olduğunu her zaman bilin. Şimdi, burada gösterdiğimden çok daha fazla kombinasyon var. Bu tam veya kapsamlı bir örnek değildir. Düzenli aralıklarla gelen yeni teknolojiler var, bu yüzden kim bilir - Son üç ay içinde ortaya çıkan bir teknolojiyi göstermemiş olabilirim. Ve yüksek kullanılabilirlik on yıl öncesine göre çok daha yaygın.
Aslında, çoğu büyük kuruluş için bu günlerde zorunlu bir iş gereksinimi olduğunu söylemek zor olmazdı. Ve bu slayda geri dönmeyi seviyorum çünkü bunun zorunlu bir iş gereksinimi olduğunu söyledim. Ve sağda bu iki tablo var. En üstteki SQL Server belgelerinin dışında ve en üstteki Oracle belgelerinin dışında. Ve bunlar ne, bunlar seçmenize yardımcı olan tablolardır, hangi çoğaltma yöntemini kullanmalısınız.
Ve bazı çok basit sorularla başladığınızı unutmayın. Ne kadar veri kullanmama izin veriliyor? Ve cevap sıfırsa, yalnızca bu üstteki grafikte ilk veya dördüncü satırı seçebileceğinizi bilirsiniz. Sonra başka bir soru soruyorsun. Peki, iyileşme için ne kadar zaman alabilirim? Ve birisi der ki, saniyeler, dakikalar, o zaman bu sizin için seçimler yapar. Ve sonra, yük devretme otomatik olmalı mı yoksa manuel olarak birinin yapması gerekiyor mu? Ve bu başka bir iş sorusu. Otomatik olarak istediklerini söyleyebilirler, çünkü bilirsiniz, bir tırmanma prosedürüne güvenmek istemezler ve sonra birisine bir bilet atanır ve sonra sorunu çözer. Sadece düzeltilmesini istiyorlar.
Bunların hepsi işle ilgili sorulardır ve aşağı inip Oracle için aynısını yaparsam aynı sorular. Ve soruyorum, tamam, ne tür bir başarısızlığa izin veriyorum, ne tür bir süre, ne kaybedebilirim, kurtarma prosedürü nedir? Bunların hepsi iş seçimleridir, bu yüzden eğer iş bana üç ya da dört sorunun cevabını söylerse, işim gerçekten kolay, buraya geliyorum, bu maçlardan hangisine en yakınını seçiyorum ve sonra bunu inşa ediyorum. Unutmayın, bulutta, bunları uygulamak sadece birkaç onay kutusu olabilir.
Ve böylece, bu beni materyalimin sonuna getiriyor ve bunu sorulara açma zamanı.
Eric Kavanagh: Pekala Dez, belki önce sen sonra Robin?
Dez Blanchfield: Kesinlikle. Aslında, Twitter'da olmayanlar için muhtemelen biraz haksızlık, ama sadece herkesin zihninde görselleştirmek istediğim bir grafiğin resmini tweetledim ve daha sonra soruyu buradaki çağrıda öğrenilen arkadaşımıza göndermek istedim. Bu alanda tescilli ve açık kaynak olduğunu düşündüğümde - bu genellikle bahsettiğimiz şeydir, Oracle ve Microsoft ve benzeri şeylerden tescilli veritabanları, açık kaynaklara karşı - tescilli dünyanın İnternet yazılım satıcısı veya yazılım geliştiricisi veya şirket bu karmaşıklığı oluşturmak için organlara yatırım yapar. Böylece, yazılımı satın aldığınız bir senaryo ile sonuçlanırsınız ve satın aldığınız için birçok kişiye yatırım yapmanız gerekmez. yerleşik ve açık kaynak yeteneği - yazılım için ödeme yapmazsınız veya düşük maliyet, diyelim, ancak yazılım için ödeme yapmazsınız, ancak gövdelere yatırım yapmanız gerekir.
Ve düşüncelerinizi dengelemeye meraklıyım, özellikle de / veya alabileceğiniz bulut modellerine geçiyoruz. Ne olursa olsun AWS veya Azure ve Rackspace'inize gidebilir ve veritabanı platformunuzu sağlayan bir hizmet olarak satın alabilir veya açık kaynak koduyla yapabilirsiniz. Ve az önce bahsettiğimiz şey, tescilli ve açık kaynak arasındaki dengeleme nedir ve bahsettiğiniz tasarım modellerinin nasıl etkili olduğu ve bu konuyla ilgili genel düşünceleriniz nelerdir, özellikle de kullanılabilirlik sağlama konusunda?
Bert Scalzo: Bu soruyu ele almaya çalışırken karşılaştığım büyük öğelerden biri, müşteriye geri dönüp performans gereksinimleri hakkında sorular soruyorum. Bunu yapmamın nedeni, en azından tarihsel olarak ve kendi tecrübelerime göre, çoğaltmalarında yüksek verim isteyen müşteriler söz konusu olduğunda, veritabanı tarafından sağlanan çoğaltma ile neredeyse her zaman daha iyi olduğumu buldum. daha doğal bir şekilde yerleşik olduğu ve daha düşük bir seviyede olduğu için ve bazen açık kaynaklı bir çözümde bile dış dünya için mevcut olmayan mekanizmaları kullanır.
Size sahip olduğum bir vakaya iyi bir örnek vereceğim. MySQL'i veritabanı olarak kullanan internet tabanlı bir şirketim vardı ve MySQL'in eski bir sürümünde, Sürüm 4.0 gibi ve düğümleri arasındaki çoğaltma, veritabanlarını ne kadar büyük ölçeklendirebileceklerine dair sınırlayıcı faktördü. Ve üçüncü taraf bir çözüm satın almak istiyorlardı, sonra da "Belki açık kaynak çözümlerinden birini kullanabiliriz" diye bakıyordu. Ve gerçekten kaynatılan şey, tek yapmaları gereken MySQL'lerini Sürüme yükseltmekti, sanırım 5.5'e gittik, çünkü bu iki veritabanı sürümü arasındaki fark MySQL çoğaltmasının 4.0 Sürümü'ndeydi ve Sürüm 5.0'da öyleydi ve bu onlar için en iyi yoldu.
Şimdi, diğer seçeneklere baktık, ancak belirleyici faktör performans ve veritabanı satıcısı çözümüyle kalmaktı ve veritabanı yükseltmesini yapmak, birlikte gitmeleri için gereken performansı elde etme olasılığını en üst düzeye çıkarmak için en iyi çözümümüz oldu. daha yüksek kullanılabilirlik.
Dez Blanchfield: Evet, dürüst olmak gerekirse kendi düşüncemi yansıtıyor. Tam açıklama için ve markalara girmeyeceğim, ancak OEM'ler ve yazılım satıcıları ve genel olarak IOC'ler için çalışan tescilli bir geçmişe sahibim ve bu kesinlikle benim deneyimimdi ve aynı zamanda çok profesyonelim -open-source ve ismini vermeyeceğimiz bir grup projeye kod katkısı yapıyorum, ancak size büyük bir kuruluşsanız - bir banka olduğunuzu veya ne yapabilirsiniz her zaman bir BT mağazası olmak istemezsiniz. Örneğin, bir gazete yayıncısıysanız veya bir perakendeciyseniz, gazete yayınlayan bir BT dükkanı olmak istemezsiniz, aslında sadece BT'yi kullanan bir gazete dükkanı olmak istersiniz.
Ve böylece, yazılım geliştiricilerin araçta tüm bu yetenekleri, yük dengelemesini ve benzerlerini oluşturduğu tescilli yeteneklere yatırım yapmak, bir dotcom başlangıcı veya başka bir şey olmanıza karşı çok daha mantıklıdır. bunun gibi insan vücuduna yatırım yapabilir. Bunun nereye gittiğini görüyorsun?
Muhtemelen Dr. Robin Bloor'a teslim etmeden önceki son sorum, çünkü zamanýmýn az olduđunu biliyorum. Bunun trend açısından nereye gittiğini görüyorsunuz? Yani, her zaman dışarıdasınız, eşyaların kanama kenarındasınız, insanların oturduğunu ve dikkat ettiğini ve bunu günlüklerinin ticari bir parçası yapma ihtiyacına uyandığını görüyor musunuz? yönetim kurulu odasına günlük konuşma? Yoksa hala inek çiftliği, teknisyenler ve kapüşonların kullanılabilirlik hakkında düşündüğünü görüyor musunuz, çünkü bir şey çevrimdışı olduğunda sabah saat dörtte uyanıyorlar mı?
Trendin şu anda her büyüklükteki kuruluşa, havayolu, bankacılık ve finans gibi bariz kuruluşlara değil, sadece genel olarak işletmelere doğru sallandığını düşünüyor musunuz? İnsanların veritabanı ortamlarını korumak ve yüksek kullanılabilirlik sağlamak ve buna yatırım yapmak için gerçekten değer önerisinden kurtulduğunu mu düşünüyorsunuz yoksa sizce hala bir yolumuz var mı? Piyasadaki genel anlam nedir?
Bert Scalzo: Şu anda, hala bir boşluk olduğunu düşünüyorum, ama bir boşluk değil, çünkü işletme bunu istemiyor, çitin iki tarafı arasındaki iletişim seviyelerinde bir boşluk. Başka bir deyişle, iş adamları çok net bir şekilde, “Bu uygulamalar yüksek kullanılabilirlik gerektirir ve yüksek kullanılabilirlik dediğimizde bu özel gereksinimlere sahiptirler.” Diyorlar.
Ve bir şekilde ya da başka bir mesaj teknoloji insanlarına açıkça ulaşmıyor. Ya da teknoloji insanları geri gelecek ve “Ah, bu çok karmaşık ve size daha fazla paraya mal olacak” ve bu, şu ya da diğeri diyecektir. Bence ne olacak, nihayetinde aşınacak, çünkü dürüst olmak gerekirse, örneğin bulutta, sadece burada veya orada birkaç kutu kontrol ederek, “Bana bu gerçekten karmaşık teknoloji yapısını inşa et” diyerek teknoloji insanlarının geri dönüp iş insanlarına “Ah, pahalı” veya “Yapılması zor” ya da şu ya da bu gibi şeyleri söylemelerinin gerçekten iyi bir nedeni yok ve iş adamları bunun aslında.
Hatta kendi BT çalışanlarının gelip “Ah, istediğini elde edemezsin. Bu çok pahalı. ”Ve sonra, “ Hayır, bu doğru değil ”diyecek üçüncü taraf bir danışmanlık firması getirecekler. Bunu nasıl yapabileceğiniz aşağıda açıklanmıştır. İşte size maliyeti ne olacak. ”Yani, sanırım iki taraf arasındaki iletişim seviyeleri arasında hala otomatik hale gelmeden önce biraz zamanımız var.
Dez Blanchfield: Evet, bu kesinlikle Avustralya ve Asya Pasifik çevresinde gördüğüm şeyi yansıtıyor. Eminim küresel bir şeydir. Ve bu, yönetim kurulu odasındaki kilit karar vericilerin birçoğu, tüm iş kolları, teknik olarak çok daha anlayışlılar - blogları okuyorlar, web seminerleri izliyorlar, çeşitli makalelere ve podcast'lere ayarlandı ve etkinliklere, forumlara ve buluşmalara gidiyorlar ve şimdi seçeneklerini biliyorlar ve bulutun bir seçenek olduğunu biliyorlar.
Ayrıca, sizin de söylediğiniz gibi, şirket içi yeteneklerini getirebileceklerini biliyorlar ve bu yüzden şu an ilginç bir meydan okuma olduğunu düşünüyorum, bu konuşmaların gerçekleşmesi gerekiyor, bu da bugün yaptığımız şey, insanların, dahili olarak bir şeyler yapmaya başlayın ve sadece kahverengi çanta öğle yemeği çalıştırın ve mevcut durumumuz, ideal durumumuz nedir, nereye gitmemiz gerekiyor? Ve sonra, bunu bir araya getirin.
Özel bir mesaj aldım, şimdi sadece hızlıca değineceğim. Birisi, “Yüzde 100 kullanılabilirlik elde edebilmeniz gerçekçi mi?” Diye bir soru sordu. Beni burada düzeltebilirsiniz, ama evet diyeceğim. Elektronik fon transferi, hızlı bankacılık platformları ile EFTPOS terminalleri arasında EFTPOS geçidi için bir platform oluşturdum. Bunu 2000'lerin başında inşa ettim. Aslında 17 yıldır çevrimiçi yüzde 100'ü. Aslında, 2000'lerden önce inşa edilmişti, ancak kabaca sadece 2000/2001 üretime geçti.
Böylece, 17 yıl geliştirmeden teste ve sonra üretime geçmiştir. Bu 17 yılda, açık kaynaklı bir işletim sistemi çalıştıran, ancak tescilli veritabanı olan çok düşük maliyetli emtia PC'leri, her 90 günde bir aktif / pasif swapping yapıyor ve farklı tasarım patentleri uygulanıyor. her sunucudaki diskler, model sunucular arasında verilerin çoğaltılması, birden çok veri merkezinin çoğaltılması ve 90 gün boyunca üretim yapan veri merkezi A'dan çevrilmesi ve daha sonra veri merkezi B'ye çevrilmesi ve üretim yapılması.
Ve tersine döndüğünde, otomatik olarak yamalar ve günceller, bu yüzden sadece özel olarak aldığım soruya evet, bu mümkün, ancak bu projeye tasarım açısından çok fazla yatırımla. Yani, altyapı aslında o kadar pahalı değildi, ama tasarım ve test ve uygulama bunu elde etmek için çok pahalıydı. Bu yüzden, donanım ve altyapıya çok para harcamak zorunda değildik, ancak bulutun bir para bile olmadığı günlerde çok akıllı araçlar kullandık.
Yani, cevabın evet, şimdi bulutla daha da yapılabilir, daha önce duyduğumuz gibi, bir düğmeye tıklayarak bu özelliği etkinleştirebilirsiniz. Bunu Robin'e atacağım çünkü eminim onun da soruları var. Ama sorularıma cevap verdiğiniz için çok teşekkür ederim ve bugün mesajınızı duymayı gerçekten çok sevdim. Tamamen tüm bunlarla birlikte çünkü son 30 yıldır yaptığım her şeyi yansıtıyor.
Dr. Robin Bloor: Pekala, ben hallederim . Sunumunuzda beni büyüleyen şeylerden biri, eskiden bu tür şeylerle mücadele etmek zorunda kaldığımda mevcut olmayan seçeneklerin sayısıydı. Bu konfigürasyonları kimin tasarlayacağı ya da günümüzde bu konfigürasyonları kimin tasarlayacağı ile ilgileniyorum. Eskiden ya da alışkın olduğum dünya, oldukça ağır bir işlem sistemi olacağı ve yüksek çalışma süresi, yüksek kullanılabilirlikle ilgileneceğinizdir. Çünkü, bilirsiniz, işlem sistemi, herhangi bir şekilde düşerse pahalı olurdu. Ve bana yeni sunduğunuz tüm seçeneklere sahip olmazsınız, ancak şu ya da bu şekilde, çoğunlukla çoğaltma yoluyla, fark edilmeyecek şekilde tıklamayacak bir sıcak bekleme oluşturmanın bir yolunu bulabilirsiniz, ancak geri dönene kadar size bozulmuş bir hizmet verecekti.
Ve ben, bir nevi, bana ne gösterdiğinize bakıp bunun hakkında düşünüyorum, 15 yıldır böyle bir tasarım işi yapmadım, şimdi bu işi kim yapıyor? Bu, benim günümde olduğu gibi, bir projenin başlangıcında yaptığınız bir şey, biliyorsunuz, altyapıyı çalıştırıyor musunuz? Yoksa bu bir kuruluşta devam eden bir faaliyet midir? Çünkü ortaya çıkan yeni teknoloji seçenekleri var.
Bert Scalzo: Bilişim teknolojileri de dahil olmak üzere tüm operasyonlarında çok verimli ve etkili olan büyük şirketlerde tipik olarak merkezi bir mimari gruba sahip olacaklar veya bunun için bir isimleri olacak, “ mimarlık grubu ”. Ve tüm bu farklı resimleri, artı ve eksilerin ne olduğunu ve maliyetlerin ne olduğunu bilmek onların sorumluluğunda olacak. Ve ne olacak, belirli bir uygulama bakıyor ve “Hey, X, Y ve Z iş gereksinimlerini karşılamalıyım. Hey, mimarlık ekibi, seçimlerim neler?” Der.
Onlara cevabı verecekler, örneğin, mevcut olan iki veya üçü, ve o zaman, karar, uygulama ekibine veya uygulamanın iş sponsoruna geri dönüyor. Ancak tipik olarak, bunun üstünde kalan ve bu bilgileri hazır ve önceden oluşturulmuş olan merkezi bir grup var.
Şimdi, resmi olmayan orta ölçekli şirketler. Gerçekleşecek olan şey, bir veya iki üst düzey DBA veya sistem yöneticiniz olacak ve bu tür bir uzmanlık için gayri resmi olarak “alan uzmanı” olarak teklif edilecektir. Yani, orta ölçekli şirketlerde bile, sadece formel olmayan bir yapıda olur.
Dr. Robin Bloor: Bu gerçekten ilginç. Benim günümde, işlemsel sistemler dışında asla yüksek kullanılabilirliği düşünmeyecektik. Şimdilerde, elbette, kullanılabilirlik açısından daha da büyük taleplere tabi olan akış sistemleriniz var. Ancak, sorgu tabanlı, arka uç, analitik, veri ambarı, DI tür ortamında, orada yüksek kullanılabilirlik için gereksinimler gördünüz mü?
Bert Scalzo: Evet, bu soruyu sorduğunuza sevindim. Bir perakende firması için bazı çalışmalar yaptım ve iş için stratejik kararları büyük ölçüde veri ambarından yapacakları analizlere dayanıyordu. Aslında, Forbes Magazine tarafından röportaj yapıldı ve şirketin CEO'su, “Hey, hisse senedi fiyatımız son beş yılda yüzde 250 büyüdü ve bunun çok büyük bir nedeni, verilerimizi nasıl etkili bir şekilde kullanacağımızı bildiğimiz için İş kararları vermede o kadar iyiydiler ki, onlar için veri ambarı ve bu analizleri yapabilmek, operasyonel verilerine göre günlük bazda karar verebilmek, aslında onlar için, bir üretim sistemi.
Size bunun ne kadar önemli olduğuna dair iyi bir örnek vereceğim. Bu özel perakende satıcısıyla, bira satışlarından sorumlu olan kişi, şirketin gelirinin yüzde 60, 70'ini getirdiğinden, şirketin en önemli üçüncü yöneticisi oldu. Ve böylece, o pazarda rekabetçi kalabilmek için, her gün hangi promosyonları yapmalıyım bilmeli olmalıydı. Ve bu, bilirsiniz, sadece yılın zamanına değil, bira gibi bir şeyin satışını etkileyebilecek hava durumuna, desenlere ve diğer kritik verilere dayanabilir.
Robin Bloor: Sanırım böyle şeyler olmalı. Biraz zamanımız doldu, sanırım izleyiciden bazı soruları olması durumunda Eric'e teslim etmeliyim. Eric
Eric Kavanagh: Evet, bunların hepsi harika şeyler, Bert. Sunumunuzda izleyicilerden gelen tüm soruları ele aldığınızı düşünüyorum. Ama izlemek eğlenceli. Depolama sanallaştırması ve bunun ne kadar etkisi olabileceğinden bahsettiğinize sevindim. Yani, hepsi iyi şeyler.
Millet, tüm bu web yayınlarını daha sonra izlemek üzere arşivliyoruz. Web yayını bölümünü aramak için çevrimiçi olarak Techopedia.com'a atlayın. Tüm bu Hot Techs orada listelenecek. Uzmanlığımız için arkadaşımız Bert'e büyük bir teşekkür. Ve elbette, Dez ve Robin'e. Ve bununla vedalaşacağız millet. Kendine iyi bak. Bir dahaki sefere seninle konuşacağız. Güle güle.
