Techopediaスタッフ、2016年12月7日
持ち帰り：ホストのエリック・カバナは、空室状況についてロビン・ブロア、デズ・ブランチフィールド、IDERAのバート・スカルツォと話し合います。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ：ご列席の皆様 、こんにちは。おかえりなさい。 水曜日の東部標準時は4時であり、最近のデータの世界にいるのであれば、Hot Technologiesが再びその時を迎えています。 はい、確かに。
私の名前はエリック・カバナです。ショーのホストになります。 何がホットで、何が起きているのか、企業で使用されているクールなものは何なのか、そしてもちろん、この分野全体で私たちが行うすべての基盤にあるのはデータベースです。 そこで、データベースの保護について説明します。 正確なトピックは、「データベースを保護する：高需要データの高可用性」です。したがって、実際のスライドがあります。 そして、私については、Twitterで@eric_kavanaghを見つけました。
第一に、今年は暑く、データは暑く、ビッグデータは非常に暑いですが、それでも実際にはまだまだ最先端です。 最近の多くの最先端企業はビッグデータを活用しており、世界中のほとんどのパンとバター組織は従来のデータを使用しています。データの需要が高い場合は、確実に利用できるようにする必要があります。システムがダウンしたとき、データにアクセスできなくなったとき、それは不幸なクライアント、不幸な見込み客、顧客の混乱を招き、あらゆる種類の物事、パートナーなどを不幸にするときです。
私たちは、今日のビジネスで最高のもののいくつかから学ぶつもりです。私たちは、30年ほど実行しているデータベースの専門家であるロビン・ブロア博士から話を聞くでしょう。 ほぼ同じ期間これを行ってきたDez Blanchfieldですが、彼は本当に若いときに始めました。IDERAのBert Scalzoは本当にデータベースの黒帯です。 遠慮しないで、質問してください。このイベントの大部分は、あなたが良い質問をして、良い答えを得るときに価値があるので、チャットウィンドウまたはコンソールのQ&Aコンポーネントを介して送信してください。
そして、それで私はそれをロビン・ブロアに引き渡すつもりです–それを取り去ってください。
ロビン・ブロア博士：わかりました、クリックして動かしてみてください。 データベースについては特に説明しません。 私はイントロ、最初の紹介プレゼンテーションをしているので、あなたが知っていると思ったので、期待されるサービスレベルともちろん入手可能性について話します。これは今日のショーのトピックです。
質問は、「本当に、可用性とは何ですか？ 気づいたことの1つ-90年代に実際に気づいたこと-私は1つのサイトで作業していて、ユーザーのメールがダウンしていたために不平を言い始めました15分。
CTOまたはIT担当者が実際に、当時は実際にサービスレベルを決定した数少ない場所の1つであり、15分間停止している電子メールは誰のサービスレベルにも違反していないため、興味深いことでした。 実際のところ、2時間は許可されていると思います。 メールが使用できなかったのではなく、サーバーが切れていたため送受信できないというだけでした。 そして、それは私がそれ以来前進していることに気づいたという事実、私はすべてがただスピードアップし、ユーザーの期待もするという事実に私に警告しました、そしてこれは人々が3つのサービスレベルを持っているかもしれない状況にあなたを導きますサービスレベルが実際に違反されていない場合に文句を言うでしょう。
したがって、サービスレベルの定義は、単に提供するだけです。まあ、それは、サービスレベルの観点から話していることに正確に依存します。 ITシステムまたはITアプリケーションについて説明しました。 通常、パフォーマンス、可用性、およびメトリックの観点から定義します。つまり、測定できない限り、実際にサービスレベルを定義することはできません。したがって、通常、何らかの測定が関係し、通常は応答時間、特定のトランザクション、特定の期間にわたるシステムの可用性、および1994年から1995年頃までは、通常の稼働時間を超えてシステムを使用可能にする必要があることはほとんどありませんでした。 たとえば、午前8時から夕方6時まで、通常の期間を与えるために、たとえば、特にデータベースを使用して、システムを構築し、その方法でシステムを構築すると、特定の方法でデータベースを構成できます。バッチウィンドウが縮小し始め、一部のシステム、次に他のシステムで再度考える必要性が生じ始め、その後、以前は依存していなかったシステム間で依存関係を作り始めたサービスまたはアーキテクチャの出現がありました互いに、すべてをさらに悪化させます。 システムの可用性の面で圧迫されました。
私が言っていたのは、可用性について話すときでした。バックアップとリカバリが含まれ、次のことも含まれます。つまり、通常の用語で言う可用性だけではありません。 アプリケーションが失敗する可能性のあるさまざまな方法があります。 ハードウェア障害またはデータベース障害を取得できます。ソフトウェア障害を取得でき、それらのさまざまな種類の負荷があります。発生した場合、回復する必要があるため、バックアップも必要です。システムを起動します。 そのため、システムをバックアップするための何らかのスキームが必要です。また、最近では多くのサイトで、建物全体が破裂した場合に備えて災害復旧機能が必要になります。 そして、ここで言及する価値のあるもので、私はそれについてすぐに説明しますが、ビジネスプロセスにはサービスレベルもあり、実際にはビジネスにとって本当に重要なビジネスプロセスのサービスレベルがあります。 ITは、その一部を、合意に基づいて行う必要があります。
ITサービスレベルは通常、ビジネスプロセスのサービスレベルに付随していますが、15年前に組織が明確に定義されたサービスレベルを持つことは非常にまれでしたが、組織がビジネスプロセスに明確に定義されたサービスレベルを持つことは非常にまれです。 それは今起こっていることの一種です。 それは長い間続いてきたものではありません。
これが加速と時間の障壁です。時間の障壁に言及するだけの価値があります。 私たちは徐々にイベント処理の世界に移行します。そのため、徐々にリアルタイムの世界に移行します。そのため、24時間年中無休で必要になるまで徐々に可用性に移行します。これは、多くのシステムにとって実際には困難です。達成するのが難しい。 非常に高価であるか、場合によっては実際にシステムを変更する必要があり、使用しているデータベースソフトウェアの異なるバージョンである別のデータベースに移動する必要さえあります。
また、これらの時間の障壁-そして機会があればいつでも言及したい-これらは私たちのアプリケーションが遭遇する時間の障壁です。 ソフトウェアがソフトウェアと対話するとき、アプリケーションは可能な限り高速にしたいかもしれません。 状況によっては実際に許容できるライセンスがありません。できるだけ速くしたい場合や、市場状況のようなビジネス用語での状況です。2番目に買い注文をする人が誰かよりも悪い価格を取得する場合誰が最初に来るのか、したがってソフトウェアの速度は本当に重要です。
しかし、あなたが知っている、あなたが実際に人間とやり取りしているとき-あなたが本当に要求できる最高の応答時間は、それが人間の応答時間であるため、10分の1秒です。 人間はとにかく気付かないので、それより速く行く必要はありません。 1.1から4秒は通常人間が許容する待ち時間ですが、約4秒を過ぎるとすぐに他のことをやるので、本当にバッチアクティビティになります。
したがって、バッチ動作が理にかなっており、したがってイベント処理の世界にいないため、特定の時間枠と日、週、月があり、したがって可用性は実際に必要なものに関してかなり異なる場合があります提供できるように。 しかし、イベントの世界にいるとすぐに、24時間365日の可用性が得られ、テクノロジーの進歩はますます速くなり、可用性は向上しない可能性があります。 それはそのままです。
これは複雑さのレイヤーであり、私はこれを深く掘り下げたくありません。ただ、ここで考慮すべき3つのことがあります。 インフラストラクチャのサービスレベルがあります。これは垂直軸です。次に、任意のアプリケーションのサービスレベルがあり、次にビジネスサービスレベルがあります。これらは相互に依存しているため、考慮する必要があります。基本的に、サービスレベルが満たされるレスポンシブ環境の作成を実際に検討している場合。
そして、ここの一番下にはデータベースが表示されていますが、システム内で何でもできます。つまり、ノンストップ構成を持っていることがわかります。つまり、停止しないということです。 何らかの方法でそれを達成するさまざまな方法があるホットスタンバイの状況がありますが、何らかの方法でデータベースに障害が発生した場合、ホットスタンバイに切り替えられ、遅延はほとんどありません期間は、ユーザーがおそらく気付くが、あまり気付かない程度まで。
ウォームスタンバイは、データベースがスタンバイに切り替えられている間、誰もがヘルプデスクを呼び出してヘルプデスクを操作する20分間の切り替えに似ています。 その後、非常に長い時間がかかる再起動の状況があります。 実際に何が起こっているか、アプリケーションに実際に必要なサービスレベルが何であるかに応じて、特定のアプリケーションまたはデータベースがいずれかの状況にあることに注意してください。
それから、私は複雑さの曲線について指摘したいだけです。 複雑さは、ノードと接続、依存関係に由来します。 私たちが住んでいる世界では、あらゆるものに関係するノードと接続の数が増え続けているので、この種の便利な曲線に走っています。 複雑さが増している方法と時間ディメンションが縮小している方法を見ることができる場合、可用性レベルについて知っていますか、時間目標はありますか？
したがって、自然な進化はノンストップオペレーションに向かっています。これはもちろん、少なくとも私の経験では最も高価なものであり、作成できる最も高価な構成です。 何らかの方法で、これについて考えている組織は、現在何が起こっているかだけでなく、将来何が起こるかについて本当に考える必要があります。
おそらく最後のポイントは、サービスレベルの管理は継続的な活動であることです。 それはあなたがプロジェクトを持っていることを知っているものではありません、あなたはそれをし、それは終わりました。 そうではありません。物事は変化し続けるからです。 そうは言っても、ボールをデズに渡します。
デズ・ブランフィールド：ロビン、ありがとう。 オープニングスライドが大好きです。 私たちはちょうど再放送しました、私はそれが映画「ファインディング・ニモ2」だと思います。 Nemoが9の形式で可用性を検索しましたが、これはかなりかわいいと思いました。 常に厳しい行動をとる。 稼働時間と可用性、および高性能について考えると、火山と赤道の近くのソロモン諸島で育ったために最初に思い浮かぶイメージは、データセンターで噴火する火山です。 何かが強烈になった場合にそれが起こる可能性があるということを常に心に抱いているこのイメージがあります。 これは素敵な山の写真 カターニアのすぐ隣にあるシチリア島の北東の角にあるエトナ。
これへの私のアプローチは、あなたと会話をし、私たちが会話をしているという観点で、C-suitesと事業部門長から定期的に役員会で行うのと同じレベルでいくつかのテイクアウトを与えることです商業的または技術的な意味から組織に影響を与える可能性のあるもの、およびエンジニアリングの種類について。
特に、自動化とプラットフォームについて、高可用性とアップタイムについて話しているときに私たちが話している課題のいくつかにどのように取り組むか、そしてそれからどのように取り組むかについて考える必要があります。
したがって、最初に提起する質問は、データベースシステムとデータベースプラットフォームの可用性について話すとき、実際に何を意味するのでしょうか？ Robinがサービスレベル契約でインストールされたマッピングで、私たちが実際に何を必要とし、何を望んでいるかについて話したように、あるレベルで何かを利用可能にするという実際の課題について話すのは実際にはどういう意味ですか？
それで、今日の現実は、実際、ここに私の頭の中のいくつかのピークの現実があります-今日、すべてが事実上データベース駆動です。 現在構築されているシステムはほとんどなく、ファイルにファイルを保存したり、何らかのフラットファイルログを作成したりするような方法で構築されています。 常にすべてがデータベース駆動型です。 その結果、これらのデータベース、それらに依存し、提供、販売、または消費しようとしているサービスを提供するためにそれらに依存するさまざまなシステムとアプリケーションおよびツールの可用性について考える必要がなくなりました。 。 そして、その周辺のすべてのインフラストラクチャ。
実際、最近のデータの大きな混乱、特にデジタルネイティブまたはクラウドネイティブ、UberやAirbnbなどのように登場した一部の企業、および少し古いPayPalsについて考えるとき、そして世界のeBays –これらの組織の規模と規模は、最新のデータベーステクノロジーと最新のクラウドインフラストラクチャによってのみ可能です。 それなしでは、追加の提供された能力がなければ、それらは確かに存在しません。 9:05から9:25の間にeBayにしかアクセスできないシナリオを想像してください。iCloudやバックアップなどを実行しようとしていたため、残りの時間は利用できませんでした。働いた。
ですから、小売業、銀行業、金融業、航空会社など、日々の生活について考えるとき、他の重要な領域があります。 航空ロジスティクス、輸送船積みなどの大きな産業グループは、全体として政府があり、国家安全保障と警察などがあります。 これらのすべての業界、これらのすべての市場セグメント、すべてのこれらの組織、グループは、稼働している環境に依存しています。
ですから、それを念頭に置いて、考えなければならない他の注意事項、考えさせていただきたい他の持ち帰り、そして今、私たちの世界は「常にオン」と呼んでいます。私たちは恒久的に接続されており、これは定期的に聞くテーマです。繰り返して繰り返します。 私たちは今、毎日、一日中スマートフォンを手にしています。 私たちはそれらをオフにせず、ベッドの横に置き、常に目覚まし時計として使用し、カメラとして使用し、写真を撮って、それらの写真をクラウドに押し上げます。
彼らは常にオンであり、永続的に接続されたメンタリティです。 実際、私が使用したいフレーズコインがあります。それは今、Fitbit世代を生きているようなものです。ここですべてを測定し、すべてを監視し、ログに記録し、それはどこかに行きます。
また、別のフレーズもあります。つまり、いつでもどこか9時です。 それは私たちが住んでいる24/7/365の世界です。地球は常に太陽の周りを回っており、ある時点で、1日1時間ごとに9時です。 そして、それは人々がベッドから出て、物事をする、物を買う、物をインストールするなどを試みていることを意味します。
それでは、高可用性について話すとき、私たちは何を意味するのでしょうか？ まあ、詳細に飛び込み始めるまで、それは本当に明白に聞こえます。 それで、「OK、高可用性とはどういう意味ですか」について考えるとき、あなたは知っています。まあ現実は、特効薬はありません。 Robinは、可用性の測定やサービスレベル契約など、彼が言及したいくつかのトピックに関連していたため、非常に複雑な概念です。 次のような質問にマッピングします。質問がありますが、稼働時間ですか？ ファイブナインと呼ばれるものについて心配しますか。これについては後で説明します。 サービスレベル契約の内容を考慮しますか？ たとえば、サービスレベル契約では、遅れがあることを意味します。最近では、サービスレベル契約の3文字の頭字語がますます重要になっています。
自社運用型のセルフプロセスからサードパーティのデータセンターへのアウトソーシングおよびマネージドサービスのアウトソーシングまでのこのプロセス全体を経て、クラウドに移行します。 そして現実は、あなたがクラウドについて話すとき、それはまさに他の人のコンピューターです。 つまり、インフラストラクチャを実行しておらず、システムを実行しておらず、常にクラウドを実行していないことを意味します。 プラットフォームとして設定されたインフラストラクチャを実行しているため、営業部隊サービスではさらに重要です。 たとえば、売上を想像してみてください。そのインフラストラクチャには一切触れず、Webインターフェースにログインするだけです。
そのため、クラウドの世界で唯一のメカニズムであり、制御するあらゆる形態のインフラストラクチャをアウトソーシングします。これは、サービスレベル契約です。これが唯一のメカニズムであり、ユーザーがインストールを満たしていない場合は、どちらにも耐えられます罰金とあなたが彼らに支払う金額の減少またはあなたは彼らに支払わない。
それで、これは、高可用性をどのように管理するかという、この課題全体を思い起こさせますか？ インフラストラクチャでない場合、可用性のアップタイムをどのように管理しますか。たとえば、SLAがすべてです。 それがあなたのインフラストラクチャである場合、または設計の観点から他の誰かのインフラストラクチャである場合でも。 モデルサイエンスの負荷分散について説明しましたが、これはフォールトトレランスの設計特許ですか？
アーキテクチャでアクティブアクティブまたはアクティブスタンバイを実行していますか？ 複数のサーバー、複数のストレージプラットフォームがありますか？ これらのストレージプラットフォームはどのように動作しますか？ 彼らはお互いを複製しますか、お互いをミラーリングしますか？ RAIDを実行していますか？ 冗長ストレージ用にどのタイプのRAIDを実行していますか？ ディスクレベルでRAIDを実行していますか？ モデルドライブとモデルシステムおよびドライブ間で複製するオブジェクトストレージプラットフォームを実行していますか？ インフラストラクチャの小さな部分ごとにNプラス1ですか？ 別のデータセンターを追加しますか？それは同じデータセンターまたは別のデータセンターにありますか？ たとえば、単一の販売拠点を考慮していないデザイン特許を構築しましたか？
これらの基本的なことはすべて、今では単純な概念のように聞こえますが、これらのことのそれぞれに触れると、非常に詳細なものになります。 可用性について話すときは、常にナインについて話します。 そして、ナインとはどういう意味ですか？ 私たちは皆これらについて聞いたことがありますが、それらが何を意味するのか、なぜ重要なのかを考えてみましょう。
だから、私たちは1つの9について話します。これは可用性のわずか90パーセントです。 それは非常に高いと思います。 したがって、24 x 7 x 365の場合、たとえば1年だけを見ると、90％の時間である9の場合、1年で36日半のダウンタイムが発生します。 それをちょうど一ヶ月以上に丸めましょう。
オンラインバンキング、eBay、PayPal、LinkedIn、Twitterなどのソーシャルメディアプラットフォーム、または一般的な小売業者など、私たちが毎日取り扱っているビジネスを考えてみましょう。日当たりから米国に到着するフライトを予約したいとしましょう。オーストラリア、1週間後にアメリカに行きたいと思ったら、私のお気に入りの航空会社が36日間半の間ダウンしていたら、彼らのサービスプロバイダーが「見て、90パーセントの時間だから「？ もちろん、私はしません。
このモデルに進むと、2ナイン：99％。 まあそれは3。65日、年間およそ3日半のダウンタイムになります。 それは大したことですか？ ブラックフライデーを運営していて、特別セールを実施していて、その数日間しか購入できない場合です。
スリーナインは年間8.7時間という短い時間になりますが、年間8.7時間でさえ、8時間連続して連続しています。 銀行や金融、健康など、病院であれば、人命を犠牲にする可能性があります。 登ると、フォーナインは52分、ファイブナインは5分、シックスナインは基本的に30秒です。 シックスナインは非常に高く、このはしごを登るとき、このナインのクリスマスツリーを登るにつれて、ナインを増やすほど、デザイン、環境、プラットフォームが難しくなります。 そのサービスを提供することはより困難であり、バックアップの実行、管理、パッチ適用、あらゆる形態の停止に対するメンテナンス時間などの時間の短縮を考えると、すべての非自明な課題–そして、それはすべて、効果的に停止の割合に帰着します。
ここで伝えたいことの鍵は、前述したように、特効薬がないことです。 可用性に関しては、「万能」というものはありません。主要産業に適した特定のタイプの設計特許を取得している場合があります。 すべての銀行が同じ課題に直面しています。 いくつかはリテール銀行かもしれません、いくつかはプレミアム銀行かもしれません。 一部の銀行は、取引と投資、資産管理に焦点を合わせているかもしれません。 いくつかは純粋に消費者かもしれません。 インターネットを配置するだけで、出納係さえ持たず、現金を分配するときにATMだけを処理する場合もあります。 そのため、これらのシナリオでは、銀行業や資産管理、金融サービス業界全体でさえ、それぞれに固有のフレーバーや可用性に関して必要なものがあります。
したがって、可用性と高可用性の混合である単純な英語での可用性について考えるとき、それらは同じものであると考えますが、実際にはチョークとチーズです。 可用性とは、サーバーまたはプロセスが通常または一般に機能する時間の尺度であり、それらの使用に関連する、わかりやすい英語で示しています。 それは単に、それが利用可能かどうかを記述する方法を意味します。 可用性について話すとき、私たちはしばしば、「私はそれを利用可能な形で提供している」という考えのtrapに陥りますが、そのインフラストラクチャのセキュリティを保護する高可用性ではありません。
別の意味での平易な高可用性とは、特定の結果とデータの可用性を実装または達成する設計であり、特に年中無休（24時間365日）でその可用性が得られる場合です。ナイン。 常に100％を意味するわけではありません。 1つの環境の現実の世界では、100パーセントは技術的に不可能です。 プラットフォームが稼働しているデータベースを搭載したオペレーティングシステムの1台のサーバーでは、アプリケーションを配信して100％実行することは非常に困難です。 それで、デザインについて考え始めます。 冗長性はありますか、複製するスライドは複数ありますか？ 次に、平易な英語で言えば、可用性と高可用性のトピックがどれほど異なるかがおもしろいです。
サービスの稼働時間を保護するために可用性を高めるという課題に挑戦し始めたときに、これがどのように見えるかについてのアイデアを提供するために、本当にシンプルなグラフィカル形式でそれを置くと思いました。 左下の隅には、1つの9があります。 私たちが一般的に話しているファイブナインをレイアウトしました。 シックスナインは少しとんでもないです。 35日間の大まかな停止期間である左下隅でファイブナインについて話すとき、それはあなたが提供しようとしている低コストで複雑性の低い環境です。サービスレベル契約を引き続き満たします。
しかし、下から左から右に進み、図に9がさらに表示されるようになると、システムとプラットフォームの複製について考え始めるシナリオが得られます。 インフラストラクチャのさまざまな部分のクラスタリングと仮想化について考える必要があります。 これらのクラスターのジオロケーション、データセンターの複数のサイトについて考えなければなりません。また、目的とする業界と市場セグメントのタイプについて考えなければなりません。 それでは、どのタイプのサービスレベルを満たす必要がありますか？ 探しているサービスは何ですか？ 通信を伝えるリアルタイムのカードベースのサービスであるエリア。 兵役ですか？ そのため、このグラフは左下から右上に移動し、その曲線を通過すると、コストと複雑さが増加します。 より複雑で要求の厳しい環境になると、さらに9が必要になります。
たとえば、このグラフは非常によく似ています。つまり、コストコンポーネントと目的の可用性コンポーネントとの間のストーリーを説明しています。 そのため、左上隅に、可用性の高い複雑なシステムをマップし、その可用性が低下した場合に発生するコストと、停止時間ゼロで可用性を確保するメリットを比較します。 たとえば、左側に物事がダウンしている環境がある場合、金銭的な損失が発生する可能性があります。 商業的なビジネス戦略レベルでの意味合いになりうる法的意味合いがあります。
私は、サービスの恩恵を受けることに関する道徳的な問題でさえ、潜在的にあらゆる種類があると思います。 ヘルス業界であり、停電のコスト、顧客への影響、顧客満足度の低下、スタッフの生産性、ユーザーの生産性などを経験し始める場合。これらのことは、非常に複雑で依存性の高い、停止や損失の潜在的なリスクがある非常にリスクの高い環境。
右側では、設計に高コストと計画を投資する場合、インテリジェントな実装に投資するシナリオを目指しています。 私たちは人々にスキルとリソースを提供することに投資し、ネットワークと評価された運用環境とハードウェアとソフトウェアを高く評価しています。 高可用性が得られますが、コストが高くなります。 だから、彼らが交差する真ん中の最適な位置の揺れ動く魔法振り子スポット、私たちはわずかにコストを削減し、9のレベルと連続的な可用性である高可用性の間でジャグリングする可用性を高めますあなたが探しているサービスレベルを得るためにどれだけのお金を投資するつもりなのか、私たちが満たすための絶え間ない挑戦？
また、詳細には触れないトピックもありますが、これを取り上げて考えてほしいだけです。 設計の平均故障間隔と平均復旧時間の差。 言い換えると、より良い品質のインフラストラクチャ、より良い品質の設計、より良い品質のハードウェアとソフトウェア、そしてより良い品質のスタッフとリソースに投資して、物事をエンジニアリングし、平均故障間隔を短縮します。インフラストラクチャ、リソース、デザイン、盲目の特許への投資を減らすために、回復する高い能力は？ 言い換えれば、何かが壊れた場合、プラグインするためにそれをたくさん持っています。誰かがラップトップを持っていて、それが死んだ場合、あなたは予備のものを持っています。 あなたは彼らにそれを渡し、30秒で彼らはログインします。これらは極の非常に異なる端です。 一番上は失敗を避けるために高コストと高投資でエンジニアリングしていることを推測し、一番下は「失敗が来ることを受け入れるつもりです。そのため、私はそれを回避して失敗に備えるつもりです」迅速に回復します。」
前に述べたように、「私の可用性はあなたの可用性ではありません」と言えます。したがって、データベース環境とインフラストラクチャのサポート、データベースの実行、それの保護と高可用性の確保に関しては、実際にワンストップショップはありません。 。 誰もが自分のニーズと欲求を持っています。 ですから、これらの基本的な質問を自問する必要がありますが、それは次のとおりです。 私は単にドルとセントについて話しているだけではありません。 私は、組織として、リソース、時間、労力などから、可用性のレベルが提供できる範囲で何ができるかについて話していますか？ また、あなたのビジネスは何をサポートできますか？ したがって、現在の能力、現在のスキル、現在のインフラストラクチャ、現在調達できる資金。 したがって、実際に余裕があるものとサポートできるもののバランスをとることは興味深いバランスです。
また、次の質問を自問する必要があります。社内にはどのようなスキルとテクノロジーがありますか？ その課題の一部を外部委託できますか？ その後、物事をクラウドに移動できますか？ ソフトウェアサービスとは別にインフラストラクチャサービスを利用している場合、スタックをさらに進めていくと、そのスタックはなくなります。 プラットフォームとサービスにもっと投資する必要があり、インフラストラクチャの部分を心配する必要はありませんか、またはプラットフォームを心配する必要がないので、ソフトウェアをサービスとして見るべきですか？
どのタイプの市場と消費者または顧客にサービスを提供していますか？ テレコムで誰かが電話に出なければならず、いつもダイヤルトーンが聞こえる場合、月曜日から金曜日までの9時から5時の間に小さな小売店を開き、角の店の理髪師のような昼休みの時間。 ですから、それがどのように機能し、それがあなたの組織にとって何を意味するのか、何を提供する必要があるのかを、非常に長く考えなければなりません。
そして、オンプレミスのもの、外部でホストされているもの、潜在的にはクラウドにあるものの間の調整。 前にも言ったように、それは時間的な課題からも生じます。 IDERAの友人にこれらの問題にどう対処するかを教えてくれることを楽しみにしています。それは、希望する可用性と必要な可用性をパフォーマンスと一致させることと、ビジネスのニーズと内容市場と消費者が必要としています。
そして現実には、それは意外な偉業ではありません。 これらのことを考えるには、時間と労力とお金が全面的にかかるでしょう。 そして、常に人とスキルの能力への投資と、それらのプロセスの一部を自動化するソフトウェアとツールへの投資であり、それらの人々に生活を改善するだけでなく、非常に大規模な環境を監視し保護するための適切なツールと適切なシステムを提供しますこれらの大規模な環境の管理は、多くの場合、個々の人間の能力を超えています。
したがって、それを念頭に置いて、IDERAの友人がプラットフォームとツールについて話すための素晴らしい会話のシーンを設定し、最後に素晴らしい質問をすることを楽しみにしています。 そして、私は渡します。
ロビン・ブロア博士：わかった。 バート、私はちょうどあなたに鍵を与えた、それを奪う。
バートスカルツォ：ありがとう！ ありがとう、デズとロビン。 データの高可用性のトピックを続けます。 そして、実際にDezが話したことの多くを活用するつもりです。 したがって、選択肢、ナイン、トレードオフ、手頃な価格。 私は、データベース管理者またはトレンチに近い誰かが、それをどのように見ているのかという点で、それをもっと試してみますか？ 彼らはどのようにそれを設計しますか？ そして、それらの選択が意味するもの。
次に、データベースにとらわれないようにします。 たとえば、Oracle固有のソリューションやSQL Server固有のソリューションは描画しませんが、すべてのデータベースベンダーが提供する汎用アーキテクチャをそれらのラインに沿って描画します。 彼らはすべて異なる名前でそれを呼び出しますが、それはあなたが共通して持っている選択の1つのタイプであり、私はそれをビジネスと技術の両方の観点から、そしてそれがビジネス要件にどのように関係するかを見たいです。
そして、最も基本的な疑似高可用性ソリューションは、ストレージレベルのソリューション、仮想化レベルのソリューション、データベースレベルのソリューションにある選択肢から始めたいと思います。 そして、すべての選択肢がクラウドでも利用できるという事実も紹介したいと思います。
そのため、ここでも、データベースにとらわれないようにします。 さて、これから説明するほとんどのことは、それらがOracle、SQL Server、MySQL、PostgreSQLに存在することを知っています。 また、いくつかのサードパーティベンダーもあります。これらのベンダーは、考慮できる追加のアーキテクチャを提供するツールを作成しています。 そして、Dezが先ほど言ったように、最高のソリューションはありません。 それはすべて依存しています。 しかし、私たちが見ようとしていることには普遍的な事実が1つあります。それは、可動部品が増えることです。したがって、より複雑になり、したがってコストが高くなります。
そのため、データが重要な資産であることは誰もが知っています。 そして、誰もがデータへの高速アクセスが常に素晴らしいことを知っています。 ただし、データへの信頼できるアクセスが重要です。 そして、彼が彼の9つの例について話していたとき、あなたは本当に36½日のダウンタイムを持つ余裕がありますか？ そのデータが常に利用可能であることが重要です。 そのため、収益の損失という点では、ダウンタイムは莫大な費用がかかる可能性がありますが、さらに重要なのは、顧客の損失、または顧客の信用の損失です。 良い例を挙げましょう。 私が購入する特定のウェブサイトが遅い場合、遅いウェブサイトを持たない同様の費用で同様のアイテムを販売する新しいウェブサイトを見つけようとするかもしれません。 そして、それは顧客の損失だけでなく、顧客があなたに対して持っている善意でもあります。
現在、ハードウェアは最近非常に安くなっているため、高可用性に対する需要はますます高まっています。 繰り返しになりますが、私たちはそれをクラウドに導いていきます。 また、ストレージベンダー、データベースベンダー、仮想化ベンダー、さらにはクラウドベンダーなど、さまざまなレベルの製品を提供しています。 ですから、クラウドで本当に面白いのは、クラウドで構築できるこれらのアーキテクチャの素晴らしい写真をすべて描いた後です。多くの場合、チェックボックスをチェックするだけです。 そして、「地理的な地域を越えて複製したい」と言います。チェックボックス。 「主要なハードウェアコンポーネントの複製が必要です。」チェックボックス。 そのため、写真を理解していれば、クラウドでは、いくつかのボックスをチェックするだけで、思い描いた写真を作成できます。
ここで重要なのは、高可用性のビジネス要件は何ですか？ たとえば、単一のサイトでの障害のみを心配する必要がありますか、それとも複数のサイトで障害が発生する必要がありますか？ つまり、コンピューティングセンターを1つ持つことができ、その1つのセンターがオフラインになるかどうかは気にしませんか？ 複数のサイトにまたがるというビジネス要件はありません。 それはビジネス上の質問です。 また、通常は予算を定義するため、ビジネスがその質問に対する回答をどのように認識しているかを知ることが重要です。
ここで、障害保護のレベルも検討する必要があります。 停電の可能性がありますか？ コンポーネントの故障でしょうか？ NICやHBAが悪いように、ホストバスアダプター。 悪くなるのはハードディスクですか？ ストレージキャビネットの障害ですか？ コンピューターの障害ですか？ または、場合によっては、サイトの障害ですか？ これは、サイト自体がオフラインであるために、サイト障害が発生する場合とは異なります。 別のケースでは、サイトのかなりの部分がオフラインである可能性がありますが、あなたの観点からはそれがサイト全体です。
そして、Dezが話していたように、業務を再開する時間はどうなるのでしょうか？ それはビジネス上の質問です。 ビジネスで2分以内に運用を再開できると言われた場合、明らかに、それはこれらの写真の一部を定義します。選択できます。
また、高可用性中に出てくる別の質問ですが、多くの人が尋ねるのを忘れる場合があります。「ビジネス、トランザクションの処理中に何かが起こった場合、システムの再開時に何が失われますか？ 」 言い換えると、システムを2分で復旧でき、10秒以内に失われた場合、たとえば、飛行中のトランザクションは許容できるビジネスですか？ 繰り返しになりますが、それはビジネスがそのために費やす意思を定義するものであり、それから再び、どの写真を適用するか、または適用しないかを示します。
それでは、最も基本的な疑似高可用性ソリューションから始めましょう。 これは実際には高可用性ではありませんが、これから始めるのが好きです。なぜなら、人々が正しい方法で考えるようになるからです。 サーバーとストレージアレイがある場合、通常、そのサーバーに複数のNIC、ネットワークインターフェイスカードを配置し、それらを結合して、1つのNICに障害が発生した場合でも稼働します。 そして、ホストバスアダプターでも同じことを行い、異なるスイッチを介してマルチパスを実行するため、ストレージにアクセスする方法は複数あります。 そして、私はユニバーサル電源を手に入れ、ストレージアレイ内に繰り返しコントローラーを持ち、ディスクでRAID 10のようなことをしたかもしれません。 つまり、この図では、複数レベルでの単一コンポーネントの障害を防止しました。 したがって、NIC、HBA、コントローラー、またはスイッチに縛られることはありません。
ただし、気が付いた場合、サーバーは赤で、ストレージアレイは赤です。 サーバーに障害が発生した場合、サーバーに障害が発生した場合、ストレージアレイキャビネットに障害が発生した場合に障害が発生した場合、2つの領域がまだあります。 したがって、これは実際には高可用性ではありませんが、写真を見て、見て、「赤のない写真が欲しい」と言い始めます。 そして、それは本当に私たちを正しい方向に向けさせるために、これらの写真の目標です。
だから、最初に起こることは、DBAとして、私は常にデータベース実装として高可用性ソリューションを置きたいと思うかもしれませんが、ストレージソリューションとして行うことができるか、またはストレージレベルのレプリケーションである可能性があります。 左の場合、ストレージ仮想化があります。 何が起こっているのか、ディスクの2つの異なるストレージキャビネットにRAID 0がありますが、2つの異なるストレージキャビネットにRAID 1があります。 つまり、実際にストレージキャビネットが故障する可能性がありますが、私は死んでいません。 そのため、前の図ではサーバー上の赤とストレージアレイ上の赤の両方を覚えていたため、前の図よりも優れています。また、ストレージレベルで赤がなくなったため、少し改善されました。使用済み-ストレージ仮想化がその問題を解決しました。
さて、それを行うことができる別の方法（すべてのベンダーがこれを提供しているわけではありません）は、ストレージレベルのレプリケーションを実行できる可能性があることです。 私はデータベースの複製について話しているのではなく、実際にストレージのブロックI / Oを複製することについて話しているのです。 そして、それはストレージレベルで実行できます。 繰り返しになりますが、ストレージレプリケーションを使用しているため、右側に、下から赤を削除した別の写真があります。
したがって、これは別の写真であり、利用できない場合があります。 これを管理するのは、データベース管理者ではなく、ストレージ管理者かもしれません。 「ああ！高可用性、この問題に対処するのはDBAでなければならない」と時々考える人がいるので、私はこれを持ち出すのが好きです。 それは常に真実ではありません。 この場合、ストレージ管理者である可能性があります。
次に、可能なソリューションとしてサーバー仮想化を行うことができます。 覚えているなら、最初の写真ではサーバーで赤、ストレージアレイで赤でした。 この場合、仮想化を使用して、再配置できる場合があります。場合によっては、再配置は一種のウォームリロケーションであり、実際にはホットリロケーションになることもあります。 一部の仮想化またはハイパーバイザーは、仮想マシンを飛行中に移動する機能を提供します。 また、一部のデータベースは、飛行中のその動きを容易に受け入れます。 繰り返しになりますが、すべてのハイパーバイザーがこれを提供するわけではありませんが、これは可能なレベルのソリューションの1つです。 今、私はトップサーバーがもはや赤くならないようにしましたが、私はまだ共有ストレージアレイを持っており、このソリューションはデータベース管理者と仮想化管理者の間の共同の努力かもしれません。 または、そのハイパーバイザーとそのデータベースでサポートされている再配置のレベルに応じて、仮想化管理者だけにすることもできます。
あなたが疑問に思っているなら、「わあ、彼はこの移転によってどういう意味ですか？ たとえば、VMotionを使用して、あるホストから別のホストに仮想マシンを移動し、ダウンタイムなしでそれを行うことができるVMで。 さて、明らかに、前の写真にはまだ赤が残っていました。 私はまだ単一障害点としてのストレージを持っていました。 それで、次のソリューションに移ります。それは、ストレージとサーバー仮想化を組み合わせることです。
さて、この場合も、このソリューションを構築しているのはストレージ管理者と仮想化管理者かもしれません。 仮想マシンまたは実行中のアプリケーションまたはデータベースをあるサーバーから別のサーバーに再配置でき、2つの別々のストレージアレイでRAID 1を実行することでストレージアレイを仮想化できるため、高可用性が得られました。 スイッチとHBAをマルチパス化しました。
そのため、今ではHAシステムを構築し、主にデータベースレベルでは構築していません。 言い換えれば、同じことを達成するために他のテクノロジーを使用しました。 したがって、これは解決策です。 次に、共有ストレージのスケーラブルなクラスターと呼ばれるものに入ります。 これは、実際にはHAソリューションではありませんが、繰り返しになりますが、私は写真でそれを見せたいです。
ここで何が起こるかというと、データベースを実行している2つのサーバーがあり、1つのデータベースと見なされます。 2つの別個のデータベースではありません。 マスターとスレーブ、またはホットとコールド、またはアクティブとスタンバイのようなものではありません。 つまり、これらのノードは両方とも連携して1つの論理データベースを提供します。 そのため、特定のノードに障害が発生しても、まだ起きています。 そのため、サーバーレベルの障害から保護し、基本的にノードリソースを分割することでそれを行いますが、ディスクの障害の底まで単一障害点が残っています。 したがって、これは共有ストレージスケーラブルクラスタであり、OracleはこのReal Application ClusterまたはRACと呼びます。
現在、別の解決策は、共有ストレージフェールオーバークラスターを使用することです。 そのため、左側にアクティブノードがあり、右側にパッシブノードがあり、その間にハートビートがあります。 共有ストレージアレイがありますが、これは非常に重要です。 あなたはそれを持っている必要があります。 基本的に、アクティブノードで問題が発生すると、パッシブノードが引き継ぐことができます。 これにはライセンスの問題があります。 一部のデータベースベンダーでは、一定の期間、ライセンスを減らしたパッシブノードを使用できます。 それ以外の場合は、完全に重複したライセンスが必要です。 それはすべて、データベースベンダーに依存します。 しかし、これらはすべてこの種の図をサポートしています。つまり、1つのノードがダウンした場合、他のノードが引き継ぐことができます。
通常、これは、アクティブノードからパッシブノードに移動するときに、おそらくすべてのデータベースではなく、ほとんどのデータベースで、一部の情報が失われるシナリオの1つです。フライトトランザクション。 次に、データベース管理者が実際に見ることができるもの、つまりデータベース複製について説明します。データベース複製を行うには2つの異なる方法があります。
物理的なレプリケーションがあります。重要なことは、この図の中央にある緑色の星で、レプリケーションがデータベースによって実行されていること、ストレージレベルの仮想化と同様にブロックで実行されていることがわかります。レベル。 そのため、アクティブノードから読み取り専用またはパッシブノードへの実際のブロックI / Oを繰り返しています。 そして、これは物理的な複製と見なされます。
さて、次のスライドに進みましょう。これはほとんど同じであり、論理的な複製であり、画像の変更点はブロックI / O経由で送信するのではなく、本質的にログ経由で送信することですSQLコマンドを含むファイル。 つまり、言い換えると、複製しているのは物理I / Oではなく、物理I / Oを引き起こすコマンドです。
そのため、これはしばしばログシッピングまたはログベースのレプリケーションと呼ばれます。 一部のデータベースベンダーは、これをネイティブに提供します。 他のデータベースベンダーはこれを提供しない場合がありますが、サードパーティベンダーが提供するため、これは非常に人気のあるHAソリューションであり、完全なソリューションと見なされます。 ただし、このソリューションは主にDBAの責任です。
そのため、これを実現するために仮想化を使用していません。 私はできましたが、それに依存していません。 また、ストレージ仮想化を使用していません。 繰り返しになりますが、私はそれに依存していません。 しかし、データベースを主な機能とするソリューションを構築しています。 したがって、これは論理的な複製です。
現在、データベースとストレージの仮想化を組み合わせることも可能です。 たとえば、データセンターで、左側の青い部分に、ストレージの仮想化を設定して、特定のストレージアレイの障害に縛られないようにすることができます。 しかし、コマンドがデータセンターでも実行されるように、あるデータセンターから別のデータセンターへのデータベースレベルのログベースまたは論理レプリケーションを行っている可能性があり、I / Oが発生しますが、必ずしも同じI / Oではありませんmストレージソリューションまたはデータベースのいずれかによって、ブロックI / Oを介して送信しませんが、ログ、したがってSQLコマンドを出荷しています。
したがって、これは非常に大規模な組織で非常に一般的な画像です。 そして、Oracleのようなデータベースを使用してオンプレミスでこれをセットアップする必要がある場合、私はそれを行うことができるので、ここでこの写真が好きです。 それはかなりの量の作業であり、かなり複雑で、多くの可動部分があります。 クラウドでこれを行う場合、文字通り「チェックボックス」、「2つの地理的領域が必要、異なる大陸で区切られた領域が必要」、「特定の地理的領域でストレージレベルの仮想化が必要」と言うことができます。 仮想化タイプの割り当てや高可用性の定義を行う機能が必要だと言うこともできますが、これもまた別のチェックボックスです。
クラウドで私が気に入っているもう1つのことは、「パッチを適用したくないので、パッチを適用したくない」という別のチェックボックスがあります。シーン、常にパッチを適用してください。 そのため、これらの写真の一部は非常に複雑になり、オンプレミスで行うのは非常に難しいかもしれませんが、実際にはクラウドで非常に簡単になりつつあります。
今、興味深いのは、すべてのチェックボックスをチェックするのは簡単ですが、それは月額ベースでより多くのお金がかかることを推測します。 2つのデータセンターを運用している場合、利用しているクラウドに2つのデータセンターがあるため、1つを使用する場合よりも多くの費用を支払うことになります。 同様に、ストレージレベルまたは仮想化の高可用性を追加レイヤーとして実行している場合も、追加のコストが発生する可能性があります。
そのため、サイトで行うのは難しく、考え直しがちですが、クラウドでは簡単に行えますが、考え直しができるのは興味深いことです。 そのため、写真がどのように見えるかを常に把握し、構築している写真がどんなものであっても、コストの影響を常に把握してください。 さて、ここで示したものよりも多くの組み合わせがあります。 これは完全または網羅的な例ではありません。 定期的に新しい技術が登場しているので、誰が知っているでしょうか。過去3か月以内に登場したばかりの技術を示していないかもしれません。 また、高可用性は10年前よりもはるかに一般的です。
実際、ほとんどの大規模な組織にとって、今日では必須のビジネス要件であると言っても、それを一筋縄では考えません。 そして、このスライドに戻るのが好きです。なぜなら、それが必須のビジネス要件だと言ったからです。 そして、私はこれらの2つのテーブルを右側に取得しました。 一番上はSQL Serverのドキュメントの外にあり、一番下はOracleのドキュメントの外にあります。 これらは、どのレプリケーション方法を使用すべきかを選択するのに役立つテーブルです。
そして、非常に簡単な質問から始めることに注意してください。 どのくらいのデータを使用できますか？ 答えがゼロの場合、そのトップチャートでは、1行目または4行目しか選択できないことがわかります。 次に、別の質問をします。 さて、回復にどれくらいの時間がかかりますか？ そして、誰かが、まあ、数秒か数分と言ったら、それはあなたのための選択をします。 そして、フェイルオーバーは自動である必要がありますか、それとも誰かが手動で行う必要がありますか？ そして、それは別のビジネス上の質問です。 彼らは、あなたが知っているように、エスカレーション手順に頼りたくないので、それを自動化したいと言うかもしれません、そして誰かがチケットを割り当てられて、それから問題を解決します。 彼らはただそれを直したいだけです。
これらはすべてビジネス上の質問であり、Oracleで同じことをした場合も同じ質問です。 そして、私は尋ねます、OK、私はどんな種類の失敗を許しますか、どんな種類の期間、私は何を失うことができますか、回復手順は何ですか？ これらはすべてビジネス上の選択なので、ビジネスが3つまたは4つの質問への答えを教えてくれたら、仕事はとても簡単です。ここに来て、最も近いものを選んでからそれを構築します。 そして、クラウドでは、実際にそれらを実装するためのいくつかのチェックボックスにすぎないことを忘れないでください。
そして、それにより、私の資料の終わりに至り、質問のためにこれを開く時が来ました。
エリック・カバナ：わかった、デズ、多分最初はロビン？
Dez Blanchfield：もちろんです 。 実際、おそらくTwitter以外の人にとっては少し不公平ですが、私はみんなの心の中で視覚化したいグラフの写真をツイートしました。そして、私はここで電話で私たちの学んだ友人に質問を投げたいと思いました。 この分野でのプロプライエタリとオープンソースについて考えると、OracleやMicrosoftなどのプロプライエタリデータベースと、オープンソースとを比較することがよくあります。インターネットソフトウェアベンダー、ソフトウェア開発者、または会社は、その複雑さを構築するために組織に投資します。そのため、ソフトウェアを購入し、購入しているので多くの人に投資する必要がないシナリオになります。オープンソースに組み込まれた機能-ソフトウェアにお金を払わないか、低コストだとしましょう。たとえば、ソフトウェアにお金を払わなくても、体に投資する必要があります。
そして、特に私たちがあなたがどちらかを手に入れることができるクラウドモデルに移行している今、私はジャグリングについてあなたの考えを得ることに熱心です。 AWSまたはAzureとRackspaceなどにアクセスして、データベースプラットフォームを提供するサービスとして購入するか、オープンソースコードを使用して購入できます。 そして、私たちが今話したこと、プロプライエタリとオープンソースの間のやりとり、あなたが話しているデザインパターンがどのように効果を発揮するか、そして私たちが前進しているとき、特に可用性の提供に関してこのトピックについてのあなたの一般的な考えは何ですか？
Bert Scalzo：その質問に答えようとしているときに出くわす大きなアイテムの1つである私は、顧客に戻ってパフォーマンス要件について尋ねます。 そして、私がそうする理由は、少なくとも歴史的に、そして私自身の経験から、レプリケーションで高いスループットを必要とする顧客に関しては、データベースによって提供されるレプリケーションの方がほとんど常に良いことです。ベンダー、より本質的に組み込まれ、より低いレベルにあるという性質のために、オープンソースソリューションであっても、外部の世界では利用できないメカニズムを使用することがあります。
そして、私が持っていた1つの事例の良い例を挙げましょう。 MySQLをデータベースとして使用しているインターネットベースの会社があり、バージョン4.0などの古いバージョンのMySQLを使用していたため、ノード間のレプリケーションがデータベースの規模を制限する要因でした。 そして、彼らはサードパーティのソリューションの購入を検討しており、次に「オープンソースのソリューションを使用できるかもしれません」と考えていました。 本当に簡単に言えば、MySQLをバージョンにアップグレードするだけでした。5.5バージョンだったと思います。これら2つのデータベースバージョンの違いは、MySQLレプリケーションのバージョン4.0にあり、バージョン5.0ではそうでしたが、実際にはそれが彼らにとって最良の道でした。
今、私たちは他の選択肢を見ましたが、決定要因はパフォーマンスであり、データベースベンダーソリューションにとどまり、実際にデータベースのアップグレードを行うことは、彼らが必要とするパフォーマンスを得るための最高の確率を得るための最良のソリューションになりましたより高い可用性。
Dez Blanchfield：ええ、それは正直に言って、私の考えを反映しています。 完全な開示のためだけに、私はブランドには行きませんが、私はOEM、ソフトウェアベンダー、IOC全般で働いている独自のバックグラウンドから来ました、それは間違いなく私の経験であり、同時に非常にプロです-open-sourceと私は名前を付けない多数のプロジェクトのコードコントリビューターですが、あなたが大規模な組織である場合、あなたが銀行であるとか、あなたがそうするかもしれないと言うことであなたに同意しますbe –常にITショップになりたくない。 たとえば、新聞社や小売店の場合、新聞を発行するITショップになりたくない、実際にITを活用する新聞店になりたい、などです。
したがって、ソフトウェア開発者がツールですべての機能、負荷分散などを構築する独自の機能に投資することは、ドットコムのスタートアップなどの場合と比べて、はるかに理にかなっています人体に投資できるようなものです。 これはどこに行くと思いますか？
おそらくロビン・ブローア博士に引き渡す前の最後の質問です。 トレンドの観点からこれをどこで見ると思いますか？ だから、あなたはいつもそこにいて、あなたはものの最前線にいます、あなたは人々が座って注意を払い、これを彼らの日々の商業的な部分にする必要性に目覚めているのを見ていますか？役員会議室への一日の会話？ それとも、オタクファーム、技術者、パーカーが可用性を考えているのを見ていますか？それは、何かがオフラインになると、朝の4時に目を覚まさせるからです。
航空会社、銀行、金融などの明白な組織ではなく、一般的な企業だけでなく、あらゆる規模の組織にトレンドが変化していると思いますか？ データベース環境を保護し、高可用性とそのための投資を提供するために、人々は本当に価値提案から抜け出したと思いますか、それとも私たちにはまだ道があると思いますか？ 市場の一般的な意味は何ですか？
Bert Scalzo：今のところ、まだギャップがあると思いますが、ビジネスはそれを求めていないので、ギャップではありません。フェンスの両側のコミュニケーションレベルのギャップです。 つまり、ビジネス関係者は、「これらのアプリケーションには高可用性が必要であり、高可用性と言うとこれらの特定の要件があります」と非常に明確に言っています。
そして、どういうわけかそのメッセージは、技術関係者にはっきりと伝わりません。 または、技術者が戻ってきて、「まあ、それは複雑だし、もっとお金がかかる」と言うでしょう。 正直に言って、たとえばクラウドで、あちこちのボックスをチェックして「この本当に複雑な技術構造を構築してください」と言うだけで、最終的には侵食されてしまうと思います。テクノロジーの人々が戻ってきてビジネスの人々に「ああ、それは高価だ」とか「それは難しい」とか、これかそれとか言う理由はまったくなく、ビジネスの人々はそれが事実。
また、自分のITスタッフが来て、「ああ、あなたは欲しいものを手に入れることができない」と言う環境でさえ見ました。 そして、彼らはサードパーティのコンサルティング会社を持ち込み、「いいえ、それは正しくありません。 方法は次のとおりです。 だから、それがまだ自動になる前に、両サイド間の通信レベルの間にはまだ少し時間があると思う。
Dez Blanchfield：ええ、それは間違いなく、ここオーストラリアとアジア太平洋地域で見たものを反映しています。 グローバルなものだと確信しています。 それは、会議室から下の多くの主要な意思決定者、すべての事業部門のトップ、彼らははるかに技術的に精通しているということです。彼らはブログを読んでいて、ウェビナーを見ています。さまざまな記事やポッドキャストに合わせて調整し、イベントやフォーラム、ミートアップに参加します。彼らは今や彼らの選択肢を知っており、クラウドが選択肢であることを知っています。
彼らはまた、あなたが言ったように、彼らの能力を社内にもたらすことができることを知っているので、今、この興味深い課題があると思います、それは基本的に私たちが人々、 、内部で物事を開始し、茶色のバッグランチを実行し、現在の状態、理想の状態、そしてどこに到達する必要があるかを内部で説明します。 そして、それをまとめましょう。
プライベートメッセージがありましたので、すぐに触れます。 誰かが「100％の可用性を実現できるのは現実的ですか？」という質問をしました。そして、ここで私を修正できるかもしれませんが、私はイエスと言います。 電子送金のためのプラットフォームを構築しました。迅速な銀行プラットフォームとEFTPOS端末間のEFTPOSゲートウェイです。 私は2000年代初期にこれを作りました。 実際、17年間は100％の時間オンラインでした。 実際、2000年代より前に構築されましたが、大体2000/2001にしか生産されませんでした。
そのため、開発からテスト、そして本番稼働に至るまで17年が経過しています。 その17年間、オープンソースのオペレーティングシステムであるが独自のデータベースを実行する非常に低価格の市販のPCは、90日ごとにアクティブ/パッシブスワッピングを行っており、さまざまな設計特許が適用され、各サーバーのディスク、モデルサーバー間のデータの複製、複数のデータセンターの複製、90日間の運用を行っているデータセンターAからの切り替え、その後データセンターBに切り替えて運用を行っています。
そして反転すると、自動的にパッチと更新が行われるので、私が個人的に得た質問だけに、はい、それは可能ですが、設計の観点からそのプロジェクトに多くの投資をします。 したがって、インフラストラクチャは実際にはそれほど高価ではありませんでしたが、それを得るための設計とテストおよび実装は非常に高価でした。 そのため、ハードウェアとインフラストラクチャに多額の費用をかける必要はありませんでしたが、クラウドが貨幣でさえなかった時代に、非常にスマートなツールを使用していました。
答えは「はい」です。ボタンを押すだけでその機能を有効にできます。 彼にも質問があると確信しているので、ロビンにそれを投げるつもりです。 しかし、私の質問に答えてくれてありがとう、そして今日私はあなたのメッセージを聞くのが本当に好きでした。 それは、私がこの30年近く行ってきたすべてを反映しているからです。
ロビン・ブロア博士：ええ、わかりました、拾います。 あなたのプレゼンテーションについて私を魅了したことの1つは、私がこのようなものと格闘しなければならなかったときに利用できなかった現在利用可能なオプションの数でした。 誰がこれらの構成を設計するのか、または最近では誰がこれらの構成を設計するのかということに興味がありますか？ かつて、または私が慣れ親しんでいた世界では、かなり重いトランザクションシステムが存在し、高い稼働率と高可用性に関心があるということです。 トランザクションシステムであるため、何らかの方法でダウンするとコストが高くなるためです。 そして、あなたが私に提示したすべてのオプションを持っているわけではありませんが、何らかの方法で、主に複製を介して、気付かないうちにクリックしないホットスタンバイを作成する方法を見つけることができますが、あなたが戻ってくるまで、それはあなたに劣化したサービスを与えるでしょう。
そして、私は、あなたが私に見せていたものを見て、それについて考えていて、15年間そのようなデザインの仕事をしていませんでした、誰が今その仕事をしていますか？ これは、今日のように、プロジェクトの開始時にインフラストラクチャを実行するために行ったことでしたか？ または、これは組織内で進行中の活動ですか？ なぜなら、新しいテクノロジーの選択肢が登場するからです。
Bert Scalzo： ITを含むすべての業務で非常に効率的かつ効果的な大企業では、通常、中央集権化されたアーキテクチャグループを持っているか、何らかの名前を持っているでしょう。アーキテクチャグループ」を何度も繰り返します。 そして、これらすべての異なる写真、長所と短所、コストを知ることは彼らの責任です。 そして、特定のアプリケーションが探しているときに「X、Y、Zのビジネス要件を満たす必要があります。アーキテクチャチーム、私の選択肢は何ですか？」
ここで利用可能な2つまたは3つがあり、その時点で、決定はアプリケーションチームまたはアプリケーションのビジネススポンサーの下位レベルに戻ります。 しかし、通常、集中管理されたグループがこれを管理し、準備ができて事前に構築された情報を保持しています。
今では、それほど正式ではない中規模企業です。 起こりがちなのは、1〜2人の上級DBAまたはシステム管理者を獲得し、その種の専門知識について「ドメインエキスパート」を非公式に引用することです。 そのため、中規模の企業でも、正式な構造ではありません。
ロビン・ブロア博士：それはとても興味深いものです。 私の時代には、トランザクションシステムを除いて、高可用性を考えたことはありませんでした。 もちろん、今日では、おそらく可用性の面でさらに大きな要求を受ける可能性のあるストリーミングシステムがあります。 しかし、クエリベースのバックエンド分析、データウェアハウス、DIのような環境では、高可用性の要件がありますか？
Bert Scalzo：ええ、そしてあなたがその質問をしてくれてうれしいです。 私は小売会社で仕事をしましたが、ビジネスに対する戦略的な決定は、データウェアハウスから行う分析の大部分に基づいていました。 実際、Forbes Magazineからインタビューを受け、同社のCEOは次のように述べています。「ねえ、株価は過去5年間で250％上昇しました。それは、データを効果的に活用する方法を知っているからです。彼らはビジネス上の意思決定が非常に上手だったので、彼らにとっては、データウェアハウスとそれらの分析を行うことができ、運用データに対して日常的に意思決定を行うことができ、実際に、実動システム。
そして、それがいかに重要であるかの良い例を挙げましょう。 ビール販売の責任者であるこの特定の小売業者では、彼は、会社の3番目に重要な経営者でした。 ですから、彼はその市場で競争力を維持するために、毎日どのプロモーションを実行すべきかを知る必要がありました。 そして、それは、あなたが知っている、あなたが知っている、一年の時間だけでなく、天気、パターン、およびビールのようなものの販売に影響を与える可能性がある他の重要なデータに基づくことができます。
ロビン・ブロア博士：そうですね、そういうものがあるはずです。 私たちは時間のようなものです、私は彼が聴衆からいくつかの質問を受け取った場合に備えて私はエリックに手渡すべきだと思います。 エリック？
エリック・カバナ：うん、これはすごいことだよ、バート。 プレゼンテーションで聴衆から寄せられたすべての質問に答えたと思います。 しかし、見るのは楽しいです。 記憶域の仮想化と、それがどれほどの影響を与える可能性があるかについてお話しいただけたことを嬉しく思います。 だから、これはすべて良いものです。
さて、皆さん、これらのウェブキャストはすべて後で見るためにアーカイブします。 Techopedia.comにオンラインでアクセスして、ウェブキャストセクションを探してください。 それらのすべてのホットテックがそこにリストされます。 友人のバートの専門知識に感謝します。 そしてもちろん、デズとロビンに。 そしてそれで、私たちはあなたに別れを告げるつもりです、皆さん。 気を付けて。 次回お話しします。 バイバイ。
