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

Slide 1

Slide 1 text

Oracle Engineered Systems 最新情報アップデート Oracle Database Technology Night #53 田口裕也日本オラクル株式会社 2022年2月24日

Slide 2

Slide 2 text

Safe harbor statement 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することを確約するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリース、時期及び価格については、弊社の裁量により決定され、変更される可能性があります。 2 Copyright © 2022, Oracle and/or its affiliates |

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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の歴史

Slide 7

Slide 7 text

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の構成

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

参考 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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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の推移を計測

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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なしで処理完了

Slide 21

Slide 21 text

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サーバ

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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の待機イベントが上位

Slide 24

Slide 24 text

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が発生

Slide 25

Slide 25 text

25 Copyright © 2022, Oracle and/or its affiliates | RATのDBリプレイを実行しながら、Swingbenchを実行したときのTPSの影響 DBリプレイのキャプチャ動作について分析レポートキャプチャファイルキャプチャファイルリプレイ・クライアント ①ワークロードをキャプチャ ②前処理 ③リプレイ ④分析 DBサーバー / ストレージクライアント APサーバー DBサーバー / ストレージ本番環境テスト環境

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 Copyright © 2022, Oracle and/or its affiliates | 統合監査でログを取得しながら、Swingbenchを実行したときのTPSの影響 20分間実行したときに取得できた監査ログ記録した監査ログの例監査ログのポリシー > CREATE AUDIT POLICY SWINGBENCH_TEST ACTIONS UPDATE ; X5 X9M X9MはX5よりもトランザクション数が多いため、監査ログの件数も増加した

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

35 Copyright © 2022, Oracle and/or its affiliates | Exadata System Softwareのアップデート方針セキュリティの最適化 ✓ Exadataに必要のない機能を排除、インストールを最適化 ✓ 必要な機能のみアクセスを許可セキュリティの重視 ✓ Exadataに必要のないサービスはすべて無効化 ✓ 必要なサービスも最小権限で実行されるように実装セキュリティの強化 ✓ Exadata全体にわたるセキュリティ・スキャンを定期的に実施 ✓ Exadata System Software の各リリースにセキュリティに関する修正を統合、万が一のゼロデイの脆弱性に対処するために緊急修正も提供

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

40 Copyright © 2022, Oracle and/or its affiliates | ExadataのLinuxカーネルについて ExadataのOracle Linuxはナノカーネルで動作 -カーネルサイズの減少（約38MB） -不要な機能を削減、 -依存性の排除、 -デバイスドライバの削減、 -フットプリントの縮小、 -アップグレード時間の短縮などの効果通常のLinuxカーネルは、約150MB

Slide 41

Slide 41 text

41 Copyright © 2022, Oracle and/or its affiliates | Exadataの最小権限の原則 Smart Scanの動作: プロセスはroot権限が不要、 celloflユーザと celltraceグループで動作 ExaWatcherの動作: iostat、netstat、ps、topなどの収集にroot権限がなくても実行できるように変更 exawatchユーザと exawatchグループで動作

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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パラメータ設定ファイルに保管

Slide 44

Slide 44 text

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の仕組みで、システムセキュリティの設定を漏れなく一括で定義

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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ログファイル時間

Slide 55

Slide 55 text

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上にファイルとして取得されたバックアップの削除を定期実行

Slide 56

Slide 56 text

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転送) 災害対策バックアップ

Slide 57

Slide 57 text

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を転送してバックアップ間のデータの隙間をカバー

Slide 58

Slide 58 text

58 Copyright © 2022, Oracle and/or its affiliates | バックアップデータの保護の違い一般的な仕組み ZDLRA NAS (NFS Server) の場所は、 OS コマンドで比較的容易に特定可能 OS権限でバックアップしたデータを窃取・消去・上書きができるバックアップ取得後に発生した、トランザクションは復旧はREDOログがないとできないバックアップからデータをリカバリできる保証はない OS権限からZDLRAの存在を特定するのは難しい ZDLRAはDBサーバとは異なる場所に配置、DB側からバックアップデータにアクセスできない DB側のREDOを損失しても、ZDLRAからデータが破壊される直前まで復旧可能 ZDLRAの仕組みによってバックアップからデータがリカバリできることが担保されるバックアップ先の特定耐改ざん性データ復旧リカバリの担保レベル

Slide 59

Slide 59 text

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のバックアップ構成

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Our mission is to help people see data in new ways, discover insights, unlock endless possibilities.

Slide 62

Slide 62 text

No content