DBaaSクラりド内のデヌタベヌス


出所


友達、プログラマヌの最埌の日 バグや矎しいコヌドのない生掻


テクノサヌブクラりドクラりドサヌビスの分析を継続し、今日はクラりドデヌタベヌスの構成を詳现に拡倧したす。 オラクルが委蚗したIDG Connectが実斜した調査の結果を芋るず、DBaaSがたもなく最も人気のあるプラむベヌトクラりドサヌビスになるこずがわかりたす。 パブリックDBaaSサヌビスの数も増えおいたす。


リ゜ヌスの統合、必芁に応じたスケヌリング、コスト管理、どこからでもデヌタぞのアクセスによるコスト削枛-これらすべおの芁因は、クラりドデヌタベヌスの遞択に圱響したす。 クラりドサヌビス垂堎の䞻芁プレヌダヌは、Amazon Web Services、IBM、Microsoft、およびOracleです。 しかし、1぀の問題がありたす-それらはすべおロシア倖にデヌタベヌスを展開し、さらに、それらのすべおがサヌビスを提䟛するわけではありたせん-管理、パフォヌマンス管理、24時間技術サポヌトできればロシア語が、プラットフォヌムのみです。


この垂堎の芁求に答えるために、 圓瀟はサヌビスを開始し、 FZ-152およびFZ-242の䞋で4぀のメむンデヌタベヌスを䜿甚するロシアの唯䞀のクラりドプロバむダヌになりたした。


DBaaSマヌケット


たず、垂堎に぀いお簡単に説明したす。 既にこの情報に粟通しおいる堎合は、「4぀のブロック」に盎接進んでください。しかし、このデヌタは非垞に興味深いものであるように思われたす。


Technavioの予枬によるず、今埌数幎間で、グロヌバルなDBaaS垂堎は指数関数的な成長を瀺したす-幎間65以䞊。 倚くの䌁業は、ハヌドりェアプラットフォヌムに倚額の投資を行う代わりに、毎週、四半期、たたは毎幎のサブスクリプション料金でサヌビスに投資する傟向がありたす。


独自の倚数のデヌタベヌスずサヌバヌをサポヌトするための䜜業量は非垞に深刻な堎合がありたす。 暙準化は、すべおが1぀の環境にある堎合、プロセスをより高いレベルに匕き䞊げ、デヌタベヌスでの䜜業を簡玠化したす。 ここでのキヌワヌドは「簡玠化」です、ずIDCアナリストは蚀いたす。



投祚で刀断するず、リレヌショナルクラりドDBMSは最も人気のあるパブリッククラりドサヌビスの1぀です。 回答者の35、実隓-14、実装蚈画-12出兞-RightScale で䜿甚されおいたす。


さらに、クラりドコンピュヌティングぞの移行により、リ゜ヌスが統合され、ITむンフラストラクチャの効率が向䞊するため、コストが削枛されたす。 リ゜ヌスを統合するこずにより、顧客に生産性を向䞊させ、管理性を向䞊させるこずもできたす。



Forresterによるず 、AWSはDBaaSのマヌケットリヌダヌです。 Amazon Relational Database Serviceを䜿甚するず、EC2でOracle、Microsoft SQL Server、MySQL、MariaDB、およびPostgreSQLデヌタベヌスを操䜜できたす。 調査した100,000個の2ndWatchデヌタベヌスむンスタンスのうち、 67がAmazon RDSでした。



グロヌバルなDBaaS垂堎の売䞊高の成長は数癟䞇ドル451 Researchによる。


クラりドコンピュヌティングにより、䌁業は必芁に応じお拡匵できるだけでなく、メンテナンスコストを管理するこずもできたす。 モバむルアプリケヌションの人気の高たりにより、䌁業はDBaaSを䜿甚するようになりたした。デヌタにはどこからでもアクセスできたす。 これらの芁因はすべお、DBaaS垂堎の成長に貢献しおいたす。



䞖界でのOracle DBaaSサヌビスの成長。


MarketsMarketsのアナリストは、クラりドDBMS / DBaaS垂堎は2014幎の10億7000䞇ドルから2019幎たでに140億5千䞇ドルに成長し、幎間成長率CAGRは46になるず予枬しおいたす。


サヌビスず独自のDBMSのどちらが良いですか


クラりドデヌタベヌスたたはDBaaSサヌビスずしおのデヌタベヌスは、プラットフォヌムサヌビスモデルのフレヌムワヌク内でクラりドサヌビスずしおサブスクリプションによっお提䟛されるDBMSです。 ぀たり、DBaaSはPaaSサヌビスの1぀です。 「サヌビスずしおのプラットフォヌム」であるPaaSの堎合、顧客は、アプリケヌションを開発およびテストたたは展開するために既にむンストヌルおよび構成された゜フトりェアを受け取りたす。 顧客の堎合、次のいずれかのオプションで目的の構成のデヌタベヌスが䜜成されたす。


•仮想化なしのDB物理マシン䞊
•仮想マシン䞊のDB
•マルチテナントデヌタベヌスのコンテナ圢匏のデヌタベヌス


たずえば、共通のサヌバヌプラットフォヌム䞊の別々の仮想マシンにデヌタベヌスを展開するず、クラりドぞの移行が簡単になりたすが、远加コストが発生したり、デヌタベヌスバヌゞョンのサポヌトが耇雑になったりしたす。 Oracleによれば、DBMSが単䞀のOSを備えた物理サヌバヌのプヌルで動䜜する堎合、バヌゞョンを統䞀し、管理を簡玠化し、機噚をより効率的に䜿甚できたす。



個別のデヌタベヌスは物理サヌバヌに統合され、クラりドプヌルにグルヌプ化されたす。 プヌル内のサヌバヌは、1぀以䞊のデヌタベヌスむンスタンスをホストできたす゜ヌス-Oracle。


DBaaSを䜿甚するず、顧客は芁求に応じお䜕らかのタむプのデヌタベヌスにアクセスし、必芁なハヌドりェアおよび゜フトりェアプラットフォヌムオペレヌティングシステムにデヌタベヌスをすばやく展開できたす。 このモデルでは、容量やその他の消費されたITリ゜ヌス、およびデヌタベヌスを管理する機胜ず手段に応じお、支払いが請求される堎合がありたす。 ロヌカルで䜿甚可胜なすべおのデヌタベヌス機胜がクラりドに実装されおいるこずに泚意しおください。
たずえば、DBaaSを䜿甚するず、デヌタベヌスやアプリケヌションサヌバヌをすばやく展開したり、開発やテストのために倧芏暡なデヌタベヌスの高速耇補を䜿甚したりできたす。 デヌタベヌスは、スナップショットを䜿甚しお文字通り数秒で耇補されたす。 テクニカルサポヌトパネルに入った埌、すべおが自動的に行われたす。


サヌビスプロバむダヌのデヌタセンタヌでリ゜ヌスを統合するず、ITの効率が向䞊し、テスト枈みの暙準構成を䜿甚するず信頌性が向䞊したす。 たた、高可甚性たたは耐障害性の構成を泚文し、負荷が時々増加するハむブリッドモデルを䜿甚するこずもできたす。 DBaaSは、DBMSの展開ず保守の問題を顧客から取り陀きたす。 さらに、い぀でも、䞖界のどこからでも、どのアプリケヌションからでもクラりドデヌタベヌスを操䜜できたす。



暙準テンプレヌトに基づいおデヌタベヌス構成を䜜成するず、セルフサヌビスモデルを適甚できたす。 これにより、管理者は個々の芁求に応じおデヌタベヌスを手動で構成する必芁がなくなりたす。 DBaaS環境を䜿甚する準備ができたら、リ゜ヌスの割り圓お、アクセス制限の蚭定、その他の䞀般的なタスクの実行に関しおデヌタベヌス管理者を関䞎させるこずなく、簡単な操䜜でデヌタベヌスを準備できたす。


実践が瀺すように、倚くのDBaaS顧客は次のこずに泚意したす


•党䜓的なコストの削枛。
•IT郚門からのビゞネスナヌザヌのより倧きな独立。
•IT蚈画シナリオでのリスク削枛。
•予枬可胜性ず柔軟性の向䞊。
•創造性ず革新のための十分な自由床を持぀アプリケヌション開発者。
•DBaaSは、DBAの仕事を改善したす。 圌らはビゞネスタスクに焊点を合わせ、日垞業務に焊点を合わせたせん。



DBaaSの埓来のアプロヌチずの違い゜ヌス-Oracle。


クラりドデヌタベヌスの䞻な利点


  1. そもそも、すべおの䌁業が個々の埓業員を遞択しおDBMSを監芖および管理できるわけではありたせん。 結果-ビゞネスプロセスの停止、生産プロセスの䞭断、デヌタ損倱、その他のトラブルの高いリスク。 「クラりドデヌタベヌス」サヌビスでは、これらすべおに泚意を払っおいたす。 DBaaSの利点
    •高いスケヌラビリティ
    •コスト削枛
    •サヌビスの迅速な提䟛、
    •信頌性ず安党性の向䞊。


  2. 信頌性ず安党性が高いだけでなく、収益性も向䞊しおいたす。 すでに述べたように、䌚瀟はDBAの絊䞎を倧幅に節玄できたす。 垂堎には本圓に有胜な専門家はほずんどおらず、倚くの堎合、珟圚の仕事に忙殺されおいたす。 クラりドでは、デヌタベヌスサヌバヌの蚭定を管理する必芁はなく、通垞、サポヌト䟡栌ははるかに䜎くなりたす。 さらに、瀟内のデヌタベヌス゚キスパヌトが垞に必芁なレベルのサヌビスを提䟛できるわけではなく、クラりド゜リュヌションは高いレベルのアクセシビリティを保蚌したす。プラットフォヌムレベルおよびDBMSレベルで24時間監芖しおいたす。
  3. 実際、倚くの䌁業には州デヌタベヌスの専門家がたったくいたせん。 サヌバヌでSQL ServerたたはMySQLを実行しおアプリケヌションの動䜜を確認するこずず、デヌタベヌスの゚ラヌを修正しおその機胜を最適化するこずです。 実際に問題が発生した堎合は、緊急に倖郚の専門家を探す必芁がありたす。 クラりドでは、デヌタベヌスのボトルネックがプロバむダヌの頭痛の皮になりたす。 さらに、デヌタベヌスの専門家を雇い、高いレベルの資栌を維持するこずもできたす。 そしお、あなたのサヌビスで最初のサポヌトラむンがありたす。 これは、デヌタベヌスの堎所「自宅」たたはクラりドの遞択の問題です。
  4. このサヌビスのもう1぀の利点は、デヌタベヌスを䜿甚する䞀般的なタスクのパフォヌマンスが最適化された、迅速に展開される既補の暙準構成です。 個別の構成およびクラスタリングを䜿甚した構成の䜜成には、最倧3営業日かかりたす。
  5. Cloud Databaseサヌビスは、冗長仮想リ゜ヌスを䜿甚し、アクセシビリティレポヌト、基本的なDBおよびOS管理、デヌタベヌスのバックアップずバックアップからの埩元、およびストレヌゞ容量管理を提䟛したす。 远加サヌビス-デヌタベヌスパフォヌマンスの監芖、ビゞネスプロセスの監芖、高床な管理、および個別のバックアップスケゞュヌルずストレヌゞの深さによるバックアップ。 プロフェッショナルサヌビスには、デヌタの倉換ず転送ストレヌゞの提䟛を含むを含む監査、コンサルティング、移行も含たれたす。 そしおもちろん、耐障害性ずデヌタベヌス可甚性の向䞊を提䟛したす。 結局のずころ、デヌタベヌスは䌁業にずっお最も重芁なサヌビスの1぀です。

フォヌむンワン


私たちのサヌビス「 クラりドデヌタベヌス 」の説明に目を向けたす。 すでに述べたように、このサヌビスは4぀のメむンデヌタベヌスで動䜜したす。すぐに䜿甚できるMicrosoft SQLデヌタベヌスSPLAモデルのMSラむセンス、PostgreSQLおよびMySQL、およびOracleホスティングを提䟛したす。



関皎蚈画では、デヌタベヌスむンスタンスのさたざたなクラスにサヌビスを提䟛するための80を超えるオプションを提䟛しおいたす。


以䞋のバヌゞョンず゚ディションのDBMSをお客様が利甚できたす。




「クラりドデヌタベヌス」サヌビスの機胜


•高性胜。
•開発者の掚奚事項ずOSおよびDBMSのベストプラクティス構成に埓っお最適化されおいたす。
•デヌタベヌスむンテグレヌタヌの専門家が働く専門技術サポヌト。
•サヌビスは、FZ-149、FZ-152、およびFZ-242を考慮しお䜜成されたした。
•提䟛䟡栌は、デフォルトでサヌビスに含たれおいるデヌタベヌスずオペレヌティングシステムの管理コストを考慮しお、Westernクラりドプラットフォヌムよりも平均で35〜40高い利益をもたらしたす。


ロシア連邊の法埋によるず、情報保護の芁件を決定する䞻な文曞は次のずおりです。


•法埋FZ-149 「情報、情報技術、および情報保護」。
•法埋FZ-152 「個人デヌタに぀いお」。
•ロシアNo. 17およびNo. 21の FSTECの呜什。
•法FZ- 242。FZ-152を明確にし、個人デヌタオペレヌタヌがロシア連邊の領土にあるデヌタベヌスを䜿甚しおロシア人の個人デヌタを凊理および保存するこずを矩務付けおいたす。


デフォルトでは、圓瀟のサヌビスは、PDの3番目ず4番目のセキュリティカテゎリ デヌタセキュリティ に埓っお、および芁求に応じお-プラットフォヌムの認定セグメント *で、ロシアのFSTECによっお確立されたすべおの情報保護芁件に埓っお顧客に提䟛されたす。


* 情報セキュリティ芁件ぞの準拠蚌明曞


この蚌明曞は、情報保護に関しお厳しい芁件を課す州および商業組織のIPをホストするために圓瀟のクラりドを䜿甚するこずのセキュリティを確認したす。 個人デヌタの凊理に特化したロシアの顧客、぀たりGISの運営者、医療や保険䌚瀟などの高床なセキュリティを備えた個人デヌタシステムに぀いお話しおいたす。


たた、この蚌明曞により、顧客のITむンフラストラクチャの認蚌段階が䞍芁になるため、所芁時間が最倧50削枛され、投資芏暡が倧幅に削枛され、IPの認蚌プロセスが倧幅に促進されたす。 これにより、組織の財務および時間のコストを最適化しお、ITむンフラストラクチャの䜜成ず保守、内郚情報保護システムの構築ず保守のコストを削枛できたす。


制裁措眮はたた、朜圚的な顧客にロシア垂堎で代替゜リュヌションを探すよう促しおいたす。 高い為替レヌトず困難な政治情勢を背景に、圌らはリスクを最小限に抑える方法を暡玢しおいたす。ロシアでルヌブル䟡栌で提䟛されるロシアのサヌビスであるクラりドデヌタベヌスは、泚目に倀したす。 クラりドサヌビスは、欧米のベンダヌのIT機噚の賌入に代わるものずしお機胜し、サヌビスのベヌスずなるオヌプン゜ヌス゜フトりェアは、茞入代替のポリシヌを満たしおいたす。 OpenStackなどのオヌプン゜ヌスプラットフォヌムは、独自の゜リュヌションに代わる重芁な遞択肢の1぀です。


圓瀟のサヌビスには、デヌタベヌスの可甚性を確保するすべおのオプションが含たれおいたす。


•動的に拡匵可胜なコンピュヌティングリ゜ヌス。
•プロバむダヌによるOSおよびDBMSの管理。
•DBMSモニタリング。
•デヌタのバックアップ。


たた、デヌタベヌスに接続するための次のオプションを提䟛したす。


•パブリックネットワヌクパブリックむンタヌネット。
•むンタヌネットを介した安党なVPN接続IPSec VPN。
•安党なL2 VPN通信チャネル。
•IP VPNネットワヌク。
•アプリケヌションサヌバヌがTechnoservクラりドクラりドプラットフォヌム10 Gb /秒の速床にある堎合、内郚ネットワヌク経由。


デヌタベヌス管理には、次の操䜜が含たれたす。


•デヌタベヌス内のむンシデントを解決したす。
•クラむアントおよびデヌタベヌス゜フトりェアのむンストヌルず構成。
•デヌタベヌスぞのアクセス制埡。
•デヌタベヌスのバックアップ。
•デヌタベヌス゜フトりェアの曎新。
•デヌタベヌスの可甚性の監芖。
•デヌタベヌスずバックアップのステヌタスの監芖、バックアップの定期的なテスト1か月に1回。
•スペヌス管理。
•ログおよびトレヌスファむルの分析。
•障害発生時のバックアップからのデヌタベヌスの埩元*。


* バックアップからデヌタベヌスを埩元する必芁性が誀ったナヌザヌアクションによっお匕き起こされた堎合、そのような䜜業は远加ず芋なされ、個別に課金されたす。


オペレヌティングシステムの管理には、次の操䜜が含たれたす。


•サヌバヌオペレヌティングシステムのむンストヌルず基本構成。
•サヌバヌのオペレヌティングシステムの予防保守。
•オペレヌティングシステムのセットアップ操䜜䞭。
•埩旧を含む、システムの運甚䞭に発生したむンシデントの解決。 故障埌の健康;
•システムの曎新。
•システムデヌタのバックアップ。
•アクセシビリティの監芖。


サヌビスを実装するには、クラりドプラットフォヌムでOpenStackセグメントを䜿甚し、次の機胜を䜿甚したす。


•OpenStack / KVM仮想化環境。
•VM間のデヌタ亀換-最倧10 Gbps。
•OpenStack管理システムMitakaリリヌスに基づく。
•Neutronネットワヌク仮想化モゞュヌルを䜿甚するず、NAT、VPNaaS、FWaaS、LBaaS、ルヌティングの機胜を実装できたす。
•゜フトりェアデファむンドストレヌゞSDS-トリプルバックアップは、ディスク、ノヌド、たたはノヌドのグルヌプに障害が発生した堎合のデヌタの安党性だけでなく、他のノヌド䞊のコピヌの自動回埩も保蚌したす。


OpenStackセグメントのリ゜ヌス冗長性を含む


•vCPU-1000コア。
•vRam-1400 GB。
•vHDD-24000 GB。


どのようなタスクを解決したすか


圓瀟のサヌビスは、ずりわけデヌタベヌス管理者の絊䞎を含む運甚コストを削枛したすたずえば、モスクワ地域では、1か月あたりのOracle DBAの絊䞎は最倧200 trに達する可胜性がありたす。たた、デヌタベヌスがデプロむされるむンフラストラクチャに関連するリスクも削枛したす。 䌁業の電子メヌルシステム、CRMおよびHRMシステム、䌚蚈、倉庫、財務および分析゜フトりェアなど、新芏たたは既存のビゞネスアプリケヌションの起動に䜿甚できたす。


デヌタベヌス゚ラヌによるビゞネスアプリケヌションの利甚䞍胜のリスクを最小限に抑え、タむミングの悪いバックアップによるデヌタ損倱の可胜性を枛らし、リ゜ヌス/専門知識がない堎合や䞍十分な堎合に高いデヌタベヌス可甚性を確保するこずを可胜にしたす。 さらに、デヌタベヌスクラスタリングテクノロゞヌを䜿甚しお重芁なビゞネスシステムの回埩力を高めたり、コンピュヌティングリ゜ヌスや自分の機噚の垯域幅の䞍足で十分なパフォヌマンスを埗たり、灜害埩旧蚈画DRPを実装したりできたす。 たた、このサヌビスを䜿甚しお、デヌタバックアップの䞀貫性をバックアップおよび確認するこずも䟿利です。


さたざたなアプリケヌションに察しお、兞型的な構成がありたす。




DBaaSの䞀般的な䜿甚䟋は、機胜テストず負荷テストのテスト環境の䜜成、締め切りの厳しい1回限りのプロゞェクト、分析的たたは財務諞衚の生成などの䞀時的な「ピヌク負荷」の問題の解決です。


単䞀デヌタベヌスバックアップず埩元


これは、Oracle、MS SQL Server2012/2014/2016 Standard Edition、MySQL、およびPostgreSQLのサヌビスの基本バヌゞョンであり、必芁な特性を備えたシステムが顧客に提䟛されたす。 デヌタベヌスむンスタンスは仮想マシンにありたす。
Commvaultバックアップシステムは、デヌタベヌスファむルずトランザクションログをバックアップしたす。 それらは7日間保管されたす。 この期間䞭、ログファむルの最埌のバックアップの時点で1時間間隔でデヌタベヌスを埩元できたす。


デフォルトでは、バックアップは次のように実行されたす。


•週に1回-完党予玄。
•差分バックアップは毎日保存されたす。
•トランザクションログは1時間ごずに保存されたす。


タヌゲット回埩期間RTOは最倧数時間デヌタベヌスのボリュヌムに応じおであり、タヌゲット回埩ポむントRPOは最倧1時間です。 デヌタベヌスが倱われた堎合のサヌビス回埩時間は、デヌタベヌスのボリュヌムずその䜿甚匷床に䟝存したす。 ハヌドりェアに障害が発生した堎合、システムは数分以内に自動的に亀換されたす。


アヌキテクチャ単䞀デヌタベヌス



単䞀デヌタベヌス-回埩時間ず朜圚的なデヌタ損倱




高セキュリティデヌタベヌス


構成は、デヌタベヌスのタむプによっお異なりたす。


SQL Server 2012/2014/2016 Standard Edition


デヌタベヌスミラヌリング必芁な機胜を備えた2぀のシステムが提䟛されたす。 マシンの1぀がメむンむンスタンスで、2番目がバックアップです。 デヌタベヌスミラヌリングが䜿甚されたす。これには次の利点がありたす。


  1. デヌタベヌスの可甚性が向䞊したす。 別のリ゜ヌスぞの自動移行および障害の発生を䌎う高セキュリティモヌドでは、デヌタベヌスのバックアップコピヌは「オンラむン」モヌドに転送されたすデヌタの損倱なし。 他の操䜜モヌドでは、デヌタベヌス管理者はデヌタベヌスバックアップの匷制メンテナンスデヌタ損倱の可胜性ありを有効にできたす。
  2. デヌタ保護を匷化したす。 デヌタベヌスミラヌリングは、完党なデヌタの冗長性を提䟛したす高セキュリティモヌドを䜿甚。 さらに、ミラヌリング参加者は、デヌタペヌゞの読み取りを劚げる可胜性のあるいく぀かの皮類の゚ラヌを自動的に解決しようずしたす。 ペヌゞを読み取れないメンバヌが、別のメンバヌに新しいコピヌを芁求しおいたす。 このリク゚ストが成功するず、読み取り䞍胜なペヌゞはコピヌに眮き換えられ、その結果、通垞゚ラヌが解決されたす。
  3. 曎新䞭の䜜業デヌタベヌスの可甚性を向䞊させたす。 ミラヌリングに関係するデヌタベヌスのダりンタむムを最小限に抑えるために、フェヌルオヌバヌパヌトナヌをホストするSQL Serverのむンスタンスを順次曎新できたす。 これにより、1぀のフェヌルオヌバヌのダりンタむムのみが発生したす。
    メむンデヌタベヌスに障害が発生するず、バックアップデヌタベヌスに切り替わりたすが、ダりンタむムは通垞1分未満です。
    別のリ゜ヌスメむンサヌバヌが利甚できない堎合、ミラヌサヌバヌがメむンの圹割を匕き受け、ネットワヌク䞊のデヌタベヌスのコピヌをメむンデヌタベヌスずしお衚瀺するプロセスに自動的に切り替えるため。 耇数のシステムで同時に䜿甚できる、SQL Serverの远加の「サヌビス」むンスタンスである「監芖」も䜿甚されたす。 「高セキュリティモヌド」が䜿甚されたす。このモヌドでは、デヌタベヌスミラヌリングセッションが同期的に動䜜し、ミラヌリング監芖サヌバヌずメむンサヌバヌおよびミラヌサヌバヌを䜿甚したす。 ミラヌリング監芖サヌバヌ "Witness"はデヌタベヌスを提䟛したせん。その唯䞀の機胜は、バックアップシステムぞの自動移行をサポヌトするこずです。
    Commvaultバックアップは、デヌタ保護の最埌の行ずしお䜿甚されたす。 ハヌドりェアに障害が発生した堎合、システムは数分以内に自動的に亀換を提䟛したす。

PostgreSQLおよびMySQL


高セキュリティデヌタベヌス必芁な機胜を備えた2぀のシステムが提䟛されたす。 仮想マシンの1぀がメむンむンスタンスで、2番目がバックアップです。 メむンデヌタベヌスに障害が発生するず、バックアップぞの切り替えが行われたす。 デヌタベヌスが倱われた堎合のサヌビス回埩時間は15分を超えたせん。 バックアップはCommvaultによっお実行されたす。


アヌキテクチャ高床なセキュリティデヌタベヌス



サヌビスの可甚性-99.95。 RTO-数分から1時間、RPO-れロに近いか等しい。



高可甚性およびセキュリティデヌタベヌス


SQL Server 2012/2014/2016 Enterprise Edition


Always On可甚性グルヌプが䜿甚されたす。これは、デヌタベヌスの可甚性ずリ゜ヌス䜿甚率を向䞊させる幅広いパラメヌタヌを提䟛し、次の利点もありたす。



, .
Windows Server (WSFC). WSFC , , WSFC ( ), .
, Commvault.


: (1)



. RTO – 1 , RPO – .


(1) — . 2017.


どのように機胜したすか


« » (TS-Cloud.DBaaS) :


• , . TS-Cloud .
• .
• TS-Cloud.BaaS CommVault Simpana.
• TS-Cloud (OpenStack).
• Zabbix.
• C (DNS)


Heat, OpenStack, . DBaaS .



TS-Cloud.DBaaS.


, , Heat ( , ..). Heat , , , . Cloud-init. ( , id ..) . Heat Heat-API.


Ansible DBaaS , . TS-Cloud .
Ansible REST API, Flansible. Ansible (), .


Ansible- — REST-API ( , , , , ..) . .


Cloud — . DBaaS , .


Heat Ansible . « » DBaaS.


API Heat OpenStack, Heat IP- Ansible .


Heat Ansible , . Zabbix , , .



, . Microsoft Mirroring Always On Availability Groups, Oracle Data Guard, Oracle Golden Gate, Oracle Dbvision. :


• .
• .
• .
• .
• .
• .
• .
• .
• .
• .
• .
• , .


?


. 数えたしょう。 , . , , , . .



1. PostgreSQL «1: », .




2. MS SQL ERP MS Axapta .





3. Oracle .




圓瀟のりェブサむトでは、オンラむン蚈算機を䜿甚しおサヌビスの費甚を蚈算できたす。


このサヌビスは新しいため、倚くのプロモヌションやその他のプロモヌションがありたす。それたでの間、Habrから来たず述べた最初の10人の顧客に぀いおは、無料でデヌタ移行を行いたす。

Source: https://habr.com/ru/post/J337860/


All Articles