Oracle Database Technology Night #53 Oracle Engineered Systems最新情報アップデート(Exadata X9MのSwingbench実行結果)

最新のExadataX9Mのアーキテクチャ、Swingbenchを利用した性能検証結果、ZDLRAによるランサムウェア対策について

Transcript

1. Oracle Engineered Systems 最新情報アップデート Oracle Database Technology Night #53 田口 裕也 日本オラクル株式会社 2022年2月24日
2. Safe harbor statement 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とする ものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することを確約 するものではないため、購買決定を行う際の判断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリース、時期及び価格については、弊社の裁量により決定され、変 更される可能性があります。 2 Copyright © 2022, Oracle and/or its affiliates |
3. Copyright © 2022, Oracle and/or its affiliates | 3 Exadata X9M Oracle Database専用機
4. Copyright © 2022, Oracle and/or its affiliates | 4 Technology Night#34 https://www.oracle.com/jp/a/ocom/docs/20200131-technightx8m.pdf https://www.oracle.com/jp/database/events-docs/001/
5. 再掲 Exadataのストレージネットワークの構成 5 Copyright © 2022, Oracle and/or its affiliates |
6. Copyright © 2022, Oracle and/or its affiliates | 6 ExadataのX8Mから、新しいアーキテクチャー(RoCE/PMEM)を導入 高IOPS/高スループット DB CPU (Cores) 64 64 96 128 192 288 352 384 384 384 512 DB Max Mem (GB) 256 576 768 2048 4096 6144 6144 12288 12288 12288 16384 Storage CPU (Cores) 112 112 168 168 168 224 280 280 448 448 448 Storage Raw HDD (TB) ※HCモデル 168 336 504 504 672 672 1344 1680 2352 2352 3024 Storage Raw Flash (TB) ※HP / EF モデル 0 5.3 5.3 22.4 44.8 89.6 179.2 358.4 358.4 358.4 358.4 Storage Raw PMEM (TB) 0 0 0 0 0 0 0 0 0 21 21 Ethernet (GB/s) 8 24 184 400 400 400 400 800 800 800 800 Scan Rate (GB/s) ※HP / EF モデル 10.5 50 50 75 100 263 350 350 560 560 630 Read IOPS 5万 100万 150万 150万 266万 414万 450万 478万 478万 1200万 2400万 V1 2008年9月 Xeon E5430 V2 2009年9月 Xeon E5540 X2 2010年10月 Xeon X5670 2012年9月 Xeon E5-2690 X3 2013年11月 Xeon E5-2697v2 X4 2014年12月 Xeon E5-2699 v3 X5 2016年4月 Xeon E5-2699 v4 X6 2017年10月 Xeon Platinum 8160 X7 2019年4月 Xeon Platinum 8260 X8 2019年9月 Xeon Platinum 8260 X8M Infini 20 Gbps 内部ネットワーク ストレージの半導体技術 Flash OLTP高速化（Smart Flash Log, Smart Flash Cache） 分析高速化 （Columnar Flash Cache) RoCE 100 Gbps NVMe Flash PMEM InfiniBand 40 Gbps Bondingで 80 Gbpsに 2021年9月 Xeon Platinum 8358 X9M Exadataの歴史
7. Exadataの基本構成は変わらない Exadataは2台のDatabase Serverと3台のDatabase ServerでRACとASMを正しく実装した構成 7 Copyright © 2022, Oracle and/or its affiliates | 新しいゴールド・スタンダード DB • データベース・サーバ クラスタ構成（Real Application Clusters）によって、DBサーバを並列稼働、高可用性と高拡張性を実現 • ストレージ 3重化構成（Automatic Storage Management）によって、ストレージ・サーバーを並列稼働、高いI/O性能と高可用性・高 拡張性を実現 • スケールアウト 可用性と性能の向上を同時に実現するExadataの構成
8. Exadataの歴史 7年前のExadata X5と最新Exadata X9Mのスペックを比較 8 Copyright © 2022, Oracle and/or its affiliates | V1 V2 X2 X3 X4 X5 X6 X7 X8 X8M X9M 0 100 200 300 400 500 600 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 Bandwidth Read IOPS CPU Performance CPU Cores
9. 参考 Exadata X9Mのハードウェアについて 9 Copyright © 2022, Oracle and/or its affiliates | • 2 ソケットの Database Servers • 32-core Intel Ice Lake CPUs • 512/1024/2048 GB メモリ工場出荷オプション • 2x 3.84 TB NVMe SSD Local Drive • PCIe Generation 4 • Ultra-fast 100Gb/s RDMA over Converged Ethernet (RoCE) Internal Fabric • 100Gb/s active-active • インテリジェントな 2ソケットの Storage Servers • 16-core Intel Ice Lake CPUs • 256 GB Memory • PCIe Generation 4 • ストレージサーバーあたり1.5 TB Persistent Memory (Eighth Storge Server では 786 GB) • 3つのストレージ層: PMEM, NVMe Flash, HDD High Capacity (HC) Storage Extreme Flash (EF) Storage Extended (XT) Storage 2 ソケット Database Server 64 cores per server 512 GB - 2 TB DRAM 216 TB disk capacity 25.6 TB PCIe NVMe Flash 1.5 TB Persistent Memory 32 cores for SQL offload 51.2 TB PCIe NVMe Flash 1.5 TB Persistent Memory 32 cores for SQL offload 216 TB disk capacity
10. 7年前のExadata X5と最新のExadata X9MをSwingbenchを実行して計測したい 10 Copyright © 2022, Oracle and/or its affiliates | http://www.dominicgiles.com/swingbench.html
11. Swingbenchの検証パターン 11 Copyright © 2022, Oracle and/or its affiliates | 検証パターン バージョン No. 手法 検証方法 検証Exadata 1 SwingBench Order Entryを利用してTPSを計測 USERSの値を増減する（10-1000） ▪X9M ESS: 21.2.4.0.0 ▪X5 ESS: 21.2.4.0.0 And ESS: 12.1.2.3.2.160721 ▪X9M DB/GI: 19.12.0.0.210720 ▪X5 DB/GI: 19.12.0.0.210720 And DB/GI: 12.1.0.2.160719 2 統合監査 1-2の検証パターンで統合監査のあり、なしで影 響を確認 3 RAT (DBリプレイ) 1-2の検証パターンでDBリプレイのキャプチャの 負荷あり、なし（本番DBへの影響を確認） Swingbench USERS TPS Swingbench RAT(DB ) TPS
12. Swingbenchの検証構成 12 Copyright © 2022, Oracle and/or its affiliates | Parameter Value Partitioning Hash Partitioning Compression No Tablespace Type Bigfile Indexing Used All indexes Scale Factor 1TB Name Load Ratio Customer Registration 15 Update Customer Details 10 Browse Products 90 Order Products 40 Process Orders 5 Browse Orders 15 Sales Rep Query 2 Warehouse Query 1 Warehouse Activity Query 1 -User : 10,100,300,500,1000 - : 5:00min USERSの値を変更してTPSの推移を計測
13. 13 Copyright © 2022, Oracle and/or its affiliates | TPSの比較 X5とX9Mは同じ36coreで計測、セッション300の状態で約1.7倍のTPSの処理量 2,472 18,083 23,049 19,681 17,477 2,121 18,008 22,920 21,976 22,128 4,960 32,747 39,646 39,786 37,694 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 10 100 300 500 1000 X5-12c X5-19c X9M-19c Average Transactions Per Second session
14. 14 Copyright © 2022, Oracle and/or its affiliates | TPSの比較 X9MのCPUを64coreにするとさらにTPSは増進、セッション300の状態で約2倍の処理量 2,472 18,083 23,049 19,681 17,477 2,121 18,008 22,920 21,976 22,128 4,960 32,747 39,646 39,786 37,694 4,204 33,569 48,149 45,965 49,935 0 10000 20000 30000 40000 50000 60000 10 100 300 500 1000 X5-12c-36cores X5-19c-36cores X9M-19c-36cores X9M-19c-64cores Average Transactions Per Second session
15. 15 Copyright © 2022, Oracle and/or its affiliates | CPU Usage X5はセッション数300のとき、CPU使用率は90%近い CPU Utilization - taikodb01 CPU Utilization - taikodb02 User = 10 User = 100 User = 300 User = 500 User = 1000
16. 16 Copyright © 2022, Oracle and/or its affiliates | CPU Usage X9Mはセッション数300のとき、CPU使用率は80%以下を推移 CPU Utilization - cancerdb01 CPU Utilization – cancerdb02 User = 10 User = 100 User = 300 User = 500 User = 1000
17. 17 Copyright © 2022, Oracle and/or its affiliates | Response Timeの比較 X5とX9Mは同じ36coreで計測 3.6 4.9 12.0 24.2 54.4 4.2 4.9 12.3 22.7 49.0 1.8 2.6 7.0 12.4 29.8 0 10 20 30 40 50 60 10 100 300 500 1000 X5-12c X5-19c X9M-19c Average Response Time session
18. 18 Copyright © 2022, Oracle and/or its affiliates | Response Timeの比較 X9MのCPUを64coreにするとさらにResponse Timeは低下 3.6 4.9 12.0 24.2 54.4 4.2 4.9 12.3 22.7 49.0 1.8 2.6 7.0 12.4 29.8 2.4 2.7 6.0 9.7 21.8 0 10 20 30 40 50 60 10 100 300 500 1000 X5-12c-36cores X5-19c-36cores X9M-19c-36cores X9M-19c-64cores Average Response Time session
19. 19 Copyright © 2022, Oracle and/or its affiliates | X9M,19c X5,19c X9MはPMEM搭載のため、FlashCacheのヒット率が低い X5,12c X9MはPMEM搭載のため、 FlashCacheよりも先にPMEMで処理される X9MはPMEMのヒット率が高い
20. 20 Copyright © 2022, Oracle and/or its affiliates | ExadataはPMEMをCacheとREDOログの書き込み先として利用 • PMEMCache • Oracle Databaseは RDMAを利用して PMEMに格納した Cacheを読み取る • PMEMCacheは ストレージサーバ間で ミラー化して格納 • PMEMLog • OracleDatabaseの ログバッファをRDMAを利用して PMEMLog上に書き込み • PMEMLogにREDOログを 書き込むと、ACKなしで処理完了
21. 21 Copyright © 2022, Oracle and/or its affiliates | ストレージ Database Software Kernel/OS (Database Server) Kernel/OS (Storage Server) Storage Server Software 21 X9Mの DBサーバ ストレージ PMEM Database Software Flash PMEM Cacheの動作 X9MはPersistent MemoryのデータにRDMAでアクセスし、OS処理をバイパスできるためステップ数が少ない RDMA Exadata X9Mの PMEM Cacheは OSの処理、CPUの割り込み、 コンテキストスイッチ、 ディスクI/Oの負荷がない X5の DBサーバ
22. 22 Copyright © 2022, Oracle and/or its affiliates | X9M,19c X5,19c PMEM Cacheを利用したcell single block physical readの待機時間の比較 X9MはPMEMキャッシュの索引を 参照しているため、平均待機時間が短い
23. 23 Copyright © 2022, Oracle and/or its affiliates | X9M,19c X5,19c TOP EVENTについて X9Mはges resource hash list、 library cache: mutex Xの待機イベントが上位 X5も同様にges resource hash list、 library cache: mutex Xの待機イベントが上位
24. 24 Copyright © 2022, Oracle and/or its affiliates | TOP EVENTについて Library Cacheの情報から、 PL/SQLのパッケージを読み 出すリクエスト数が多い SwingBenchの仕組みから、PL/SQLを コールするため、同一のPL/SQLのコード が同時に多くのセッションから呼び出される ことによってges resource hash list、 library cache: mutex Xが発生
25. 25 Copyright © 2022, Oracle and/or its affiliates | RATのDBリプレイを実行しながら、Swingbenchを実行したときのTPSの影響 DBリプレイのキャプチャ動作について 分析レポート キャプチャ ファイル キャプチャ ファイル リプレイ・ クライアント ①ワークロードをキャプチャ ②前処理 ③リプレイ ④分析 DBサーバー / ストレージ クライアント APサーバー DBサーバー / ストレージ 本番環境 テスト環境
26. 26 Copyright © 2022, Oracle and/or its affiliates | RATのDBリプレイを実行しながら、Swingbenchを実行したときのTPSの影響 キャプチャのレポート X5のキャプチャ X9Mのキャプチャ X9MはX5よりもトランザクション数が多いため、 キャプチャサイズも増加した
27. 27 Copyright © 2022, Oracle and/or its affiliates | RATのDBリプレイを実行しながら、Swingbenchを実行したときのTPSの影響 X5の場合 RAT 無 RAT 有 RAT無は21149から、RAT有は19993に減少 （約1000TPS低下）
28. 28 Copyright © 2022, Oracle and/or its affiliates | RATのDBリプレイを実行しながら、Swingbenchを実行したときのTPSの影響 X9Mの場合 RAT 無 RAT 有 RAT無は35846から、RAT有は34148に減少 （約1700TPS低下）
29. 29 Copyright © 2022, Oracle and/or its affiliates | 統合監査でログを取得しながら、Swingbenchを実行したときのTPSの影響 統合監査の動作について もともとOracle Databaseの監査ログ取得機能は、用途によって別々に実装されていた。これを統合した機能
30. 30 Copyright © 2022, Oracle and/or its affiliates | 統合監査でログを取得しながら、Swingbenchを実行したときのTPSの影響 20分間実行したときに取得できた監査ログ 記録した監査ログの例 監査ログのポリシー > CREATE AUDIT POLICY SWINGBENCH_TEST ACTIONS UPDATE ; X5 X9M X9MはX5よりもトランザクション数が多いため、 監査ログの件数も増加した
31. 31 Copyright © 2022, Oracle and/or its affiliates | 統合監査でログを取得しながら、Swingbenchを実行したときのTPSの影響 X5の場合、UPDATEの処理を監査 統合監査 無 統合監査 有 監査無は20437から、監査有は18521に減少 （約1900TPS低下）
32. 32 Copyright © 2022, Oracle and/or its affiliates | 統合監査でログを取得しながら、Swingbenchを実行したときのTPSの影響 X9Mの場合、 UPDATEの処理を監査 統合監査 無 統合監査 有 監査無は36447から、監査有は32446に減少 （約4000TPS低下）
33. 33 Copyright © 2022, Oracle and/or its affiliates | Exadataのソフトウェアについて Oracle Database – Real Application Clusters – Automatic Storage Management Exadata System Software – Smart Scan (DB処理のオフロード) – Persistent Memory Accelerator – Smart Flash Cache – Hybrid Columnar Compression – I/O Resource Management Exadata 固 有 の 特 徴 • スケールアウトする データベース・サーバー • 最速の内部ネットワーク • スケールアウトする インテリジェントなストレージ High-Capacity Storage Server Extreme Flash Storage Server
34. 34 Copyright © 2022, Oracle and/or its affiliates | Exadata System Softwareのアップデート情報について https://blogs.oracle.com/oracle4engineer/post/software-2022-feb-jp
35. 35 Copyright © 2022, Oracle and/or its affiliates | Exadata System Softwareのアップデート方針 セキュリティの最適化 ✓ Exadataに必要のない機能を 排除、インストールを最適化 ✓ 必要な機能のみアクセスを許可 セキュリティの重視 ✓ Exadataに必要のないサービス はすべて無効化 ✓ 必要なサービスも最小権限で 実行されるように実装 セキュリティの強化 ✓ Exadata全体にわたるセキュリ ティ・スキャンを定期的に実施 ✓ Exadata System Software の各リリースにセキュリティに関す る修正を統合、万が一のゼロデイ の脆弱性に対処するために緊急 修正も提供
36. 36 Copyright © 2022, Oracle and/or its affiliates | Exadata System Softwareのアップデート方針 Exadata System Software ( / , ) System Software How to research Common Vulnerabilities and Exposures (CVE) for Exadata packages Doc ID 2256887.1 https://linux.oracle.com/cve
37. 37 Copyright © 2022, Oracle and/or its affiliates | Exadata System Softwareのアップデート方針 Oracle Linux 7 STIGのベンチマーク結果 Exadata OL7 System Hardening for STIG Security Compliance Doc ID 2614471.1 STIG DoD Exadata 93% 21.2
38. 38 Copyright © 2022, Oracle and/or its affiliates | ExadataのOracle Linuxのイメージについて ExadataのDBサーバのパッケージは721、 Oracle Databaseの実行に必要な最小限な構成（21.2の場合）
39. 39 Copyright © 2022, Oracle and/or its affiliates | Oracle Linuxのイメージについて 通常のOracle Linuxは 5000超え
40. 40 Copyright © 2022, Oracle and/or its affiliates | ExadataのLinuxカーネルについて ExadataのOracle Linuxは ナノカーネルで動作 -カーネルサイズの減少（約38MB） -不要な機能を削減、 -依存性の排除、 -デバイスドライバの削減、 -フットプリントの縮小、 -アップグレード時間の短縮などの効果 通常のLinuxカーネルは、約150MB
41. 41 Copyright © 2022, Oracle and/or its affiliates | Exadataの最小権限の原則 Smart Scanの動作: プロセスはroot権限が不要、 celloflユーザと celltraceグループで動作 ExaWatcherの動作: iostat、netstat、ps、topなどの 収集にroot権限がなくても実行 できるように変更 exawatchユーザと exawatchグループで動作
42. 42 Copyright © 2022, Oracle and/or its affiliates | ExadataのOS監査 Exadata固有の監査ルールを、 /etc/audit/rules.d/01- exadata_audit.rulesで事前に定義済み
43. 43 Copyright © 2022, Oracle and/or its affiliates | Exadataのシステムセキュリティ設定 主な設定項目 • access - ホストやネットワークなどからのユーザー・アクセス • auditd-options - auditdのオプション • banner - ログイン・バナーの管理 • fips-mode - openSSHのFIPSモード • idle-timeout - ShellおよびSSHクライアントのアイドル時間のタイムアウト制御 • pam-auth - PAM認証の設定 • password-aging - 現在のユーザー・パスワードのエージングを調整 • rootssh - rootユーザーのSSHアクセス制御 • ssh-access - ユーザーおよびグループのSSHアクセスを許可または拒否 • sshciphers - SSH暗号化のサポート制御 • ssh-macs - SSHでサポートされるMAC • sudo - sudoによるユーザー権限の制御 • get-runtime - システム構成の設定をインポートし、host_access_controlパラメータ設定ファイルに保管
44. 44 Copyright © 2022, Oracle and/or its affiliates | Exadataのシステムセキュリティ設定 /opt/oracle.cellos/host_access_control apply-defaults --strict_compliance_only • INACTIVE=0 • ログイン試行の失敗数を5に設定 • ログイン試行を1回失敗した後のアカウントのlock_timeを600に設定 • パスワード履歴（pam_unix remember）を10に設定 • パスワードの強度：pam_pwquality.so minlen=15 minclass=4 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 difok=8 maxrepeat=3 maxclassrepeat=4 local_users_only retry=3 authtok_type= • PermitRootLogin no • hard maxlogins 10 • hmac-sha2-256,hmac-sha2-512（サーバーとクライアントの両方） • パスワードのエージング -M 60, -m 1, -W 7 host_access_controlの仕組みで、 システムセキュリティの設定を漏れなく一括で定義
45. 45 Copyright © 2022, Oracle and/or its affiliates | Exadataのシステムセキュリティ設定(SELinux) host_access_controlの仕組みを経由して、 ExadataでSELinuxの機能を利用可能に （21.2～） /opt/oracle.cellos/host_access_control selinux --help -h, --help show this help message and exit -e, --enforcing set the SELinux state to enforcing -p, --permissive set the SELinux state to permissive -d, --disabled set the SELinux state to disabled (Exadata default) -r, --relabel Set the system for relabling -c, --config Display the configured SELinux state -s, --status Display the current SELinux status
46. 46 Copyright © 2022, Oracle and/or its affiliates | Exadataのシステムセキュリティ設定(SELinux) https://www.oreilly.co.jp/books/4873112257/
47. 47 Copyright © 2022, Oracle and/or its affiliates | ExadataのMemory Protection Key を使用したプロセスの保護 Exadata Storage Server Software -16 - / / - - Memory Protection Keyは ExadataX7以降の19.3～から適用
48. 48 Copyright © 2022, Oracle and/or its affiliates | ExadataのMemory Protection Key を使用したプロセスの保護 https://atmarkit.itmedia.co.jp/ait/articles/1606/01/news031.html
49. 49 Copyright © 2022, Oracle and/or its affiliates | Exadata Storage ServerのSecure Computing（seccomp）の制御 Linux Secure Computing seccomp Storage Server (19.1 • • seccomp Storage Server • Exadata System Software https://docs.oracle.com/cd/F25229_01/dbmso/new-features-exadata-system-software-release-19.html#GUID-C3B3EA6B-CBFB-48B8-A1A3-8C71A8DBE14A
50. 50 Copyright © 2022, Oracle and/or its affiliates | Advanced Intrusion Detection Environment (AIDE)の動作 • Exadata (19.1
51. 51 Copyright © 2022, Oracle and/or its affiliates | Exadataのビジョンは昔から変わらない Oracle MAA Exadata System Software OLTP DB
52. Copyright © 2022, Oracle and/or its affiliates | 52 Zero Data Loss Recovery Appliance OracleDatabaseのバックアップ/リカバリ専用機
53. 53 Copyright © 2022, Oracle and/or its affiliates | ZDLRAはOracleDatabaseのバックアップとリカバリを統合的に管理 個別システム毎のバラバラな管理 Recovery Appliance での統一管理 Oracle 11g Oracle 12c Oracle 18c Oracle 19c EE/SE Linux Windows Solaris AIX HP-UX Windows Linux Solaris AIX HP-UX EMC IBM HP NetApp
54. 54 Copyright © 2022, Oracle and/or its affiliates | ZDLRAは永久的な増分バックアップとREDO転送する仕組み フル・バックアップを送るのは初回のみ 以降は永久に増分バックアップを送る (フル・バックアップは二度と不要) 2つの増分バックアップの間の変更は、 REDO転送によって補完 A A A A A B A A B B B C A B C Lv0 Backup A A A A A B B B C C 9/1 AM 1:00 A A A B B B A A B C Lv1 Backup 9/2 AM 1:00 Lv1 Backup 9/3 AM 1:00 REDO転送 REDO転送 バックアップ転送 バックアップ転送 バックアップ転送 アーカイブ REDOログ ファイル アーカイブ REDOログ ファイル 時間
55. 55 Copyright © 2022, Oracle and/or its affiliates | ZDLRAはOracleDatabaseのバックアップの管理を簡単に 本番 backup backup Gold Silver Bronze 90日保管 30日保管 7日保管 D2Dバックアップの場合 Recovery Applianceの場合 ポリシーの例 管理するDBを、定義済み(追加可能)のポリ シーと対応付けるだけ Recovery Appliance内で、ポリシーを満たす上で 必要なブロックを自動的に管理しており、期限を過ぎ たブロックを破棄する 一般的なバックアップ環境の場合 上書き対象、削除対象、リストア対象を考える (間違えるとリカバリ不能となる) 本番 NAS NAS上にファイルとして取得されたバックアップの 削除を定期実行
56. 56 Copyright © 2022, Oracle and/or its affiliates | ZDLRAの位置付け ZFS Storage Recovery Appliance Data Guard RPO バックアップ取得時点 障害が発生する直前 (near zero) 障害が発生する直前 (zero / near zero) RTO 数分から数時間(複数回のリストアが必要） 数分から数時間 数分 管理性/ OracleDatabaseのバージョン 各DBでの実施、複数バージョンに対応/ バックアップ集約・個別管理 複数バージョンに対応/ バックアップ統合・一元管理 パッチレベルを合わせる必要があり /個別管理 プラットフォーム 複数OSに対応 複数OSに対応 同一の必要あり RTO RPO ZDLRA (Backup+Redo転送) ZFS Storage (Backup) Data Guard (Redo転送) 災害対策 バックアップ
57. 57 Copyright © 2022, Oracle and/or its affiliates | ExadataとZDLRAの位置付け Day 1 フル a Day 2 変更部分 Day N 変更部分 仮想的な フル・バックアップ 永久増分バックアップ フルバップアップ不要に Day 1 Full a 任意のデータ断面を つくりDBをリカバリ できる Exadata OracleDatabase Oracle Database 11g-21c REDOを転送して バックアップ間の データの隙間をカバー
58. 58 Copyright © 2022, Oracle and/or its affiliates | バックアップデータの保護の違い 一般的な仕組み ZDLRA NAS (NFS Server) の場所は、 OS コマンドで比較的容易に特定可能 OS権限でバックアップしたデータを 窃取・消去・上書きができる バックアップ取得後に発生した、トランザク ションは復旧はREDOログがないとできない バックアップからデータをリカバリできる保証は ない OS権限からZDLRAの存在を特定するの は難しい ZDLRAはDBサーバとは異なる場所に配 置、DB側からバックアップデータにアクセス できない DB側のREDOを損失しても、ZDLRAから データが破壊される直前まで復旧可能 ZDLRAの仕組みによってバックアップから データがリカバリできることが担保される バックアップ先の 特定 耐改ざん性 データ復旧 リカバリの 担保レベル
59. 59 Copyright © 2022, Oracle and/or its affiliates | ZDLRAはランサムウェアからOracleDatabaseのデータを保護できる 1. ランサムウェアによるバックアップデータの格納先の特定が困難 RAの存在を特定するためにはDBサーバから接続先を調査する必要ある 2. DBサーバ上にはZDLRA用のOSユーザは存在しない、 RAの存在が特定できても、別のOS環境として侵入しなおす 必要がある。DBサーバからZDLRAの間でsshを遮断することもできる 3. 万が一、ZDLRAの存在を特定されても、ZDLRAのDBユーザはバックアップ作業用の権限を付与されたユーザ、格納 済みのバックアップを改変・消去することはできない NFS SQL*Net 一般的なバックアップ構成 ZDLRAのバックアップ構成
60. Thank you 60 Copyright © 2022, Oracle and/or its affiliates |
61. Our mission is to help people see data in new ways, discover insights, unlock endless possibilities.