投稿者「climb」のアーカイブ

Veeam V12新機能:バックアップのインフラ整備

回転メディアに切り替えると、ディスクは自動的に既存の古いバックアップからクリアされます。さらに、ユーザは既存のバックアップチェーンを使い続けることもでき、現在のタスクにのみ属するバックアップを削除するか、メディア上のすべてのバックアップを削除するかの2つのオプションのうち1つを選択することができます。

Storage Compatibility Settings

v12では、SOBRリバランス機能が導入されました。Performance Tierエクステントのブロックおよびファイルストレージレベルでストレージ消費をリバランスし、エクステント間のデータ分散を均等にすることができるようになりました。この操作は、新しいエクステントを追加するときに実行する必要がありますが、常に実行する必要はありません。エクステント退避とSOBRリバランスの操作は、前述した新しいVeeaMoverエンジンを使用して、エクステント間でより効率的にバックアップを移動させます。

SOBR rebalance

また、ユーザーの要望により、マルチサイトやネットワーク環境でのトラフィックを管理するためのいくつかのインターネットルールが追加されました:

at the request of users, several internet rules have been added to manage traffic in multi-site and network environments

最後に、メール通知のOAuth 2.0対応です。SMTPによる認証に加え、Google GmailとMicrosoft 365のOAuthプロトコルによる認証をVBR V12がサポートするようになりました:

OAuth 2.0 support for email notifications

Veeam V12新機能:多要素認証とベストプラクティスアナライザー

これらの高度なセキュリティ機能により、管理者は2つの新しいツールを手に入れることができます:

多要素認証は、RFC 6238に基づくTOTP(Time-Based One-Time Passwords)の仕組みに基づく2要素認証(2FA)機能を通じてコンソールへのアクセスを可能にします。個々のアカウントに対して有効にすることができます。

Multi-factor authentication

Best Practices Analyzerコンポーネントは、バックアップサーバーと製品の構成をチェックし、セキュリティと復旧成功の可能性を向上させるための重要な変更を管理者に提案します。

The Best Practices Analyzer component checks the backup server and product configuration

Veeam V12新機能:イミュータビリティ機能の強化

イミュータブル(Immutable)バックアップ機能は、ランサムウェアからバックアップを保護する手段を実装しています。この機能は、オンプレミスとクラウドネイティブの両方のワークロードで利用でき、ストレージのライフサイクルを通じてバックアップを保護し、管理者側の操作からも保護します。また、バックアップだけでなく、アラームにも不変性を持たせることができるため、より高度なインフラ保護が可能です。

Immutability Workloads

イメージレベルでのバックアップのサポートに加え、NASストレージ、スタンドアロンエージェント、AWSとMicrosoft Azureのバックアップ(Azure Blob Storageも)、HPE StoreOnceストレージでバックアップのイミュータビリティが利用可能です。また、トランザクションログやエンタープライズアプリケーションに対しても、プラグインを介して利用することができます。

Veeam V12新機能:オブジェクトストレージへの直接バックアップ

Object Storage

V12では、Direct-to-ObjectとDirect-to-Cloudの2つの主要な機能を提供しています。最初の機能は、バックアッププロキシやエージェントからオブジェクトストレージに直接バックアップを送信することで、中間ステップを回避することができます。さらに、このようなストレージへの直接接続が不可能な場合、トラフィックはゲートウェイサーバーの弾力的なプールを介してリダイレクトされることができます。さらに、ROBO(Remote Office Branch Office)環境を含め、より効率的なクラウドへの直接バックアップを実装しています。

また、新しいSmart Object Storage API(SOSAPI)ソフトウェア・インターフェースにより、オブジェクト・ストレージ・ベンダーがVeeam Backup & Replication v12と深く統合できるようになったことも特筆に値する(パフォーマンスの向上とユーザー・エクスペリエンスの改善に向けて)。

依存関係と回復の順序の設定

分散システムに障害が発生した場合、コンポーネントやサービス間に多くの依存関係が存在する可能性があるため、どのように復旧させるか判断が難しい場合があります。ここでは、分散システムで依存関係を管理し、復旧の順序を設定するための主な考慮事項を紹介します:

重要な依存関係を特定する: 重要な依存関係の特定:まず、システム内のさまざまなサービスやコンポーネント間の依存関係をマッピングすることから始めます。システムの機能にとって最も重要な依存関係を特定し、これらの依存関係に障害が発生した場合の影響を判断します。

依存関係の優先順位付け: 重要な依存関係を特定したら、システム機能への影響と、他のサービスやコンポーネントが依存する度合いに基づいて、依存関係の優先順位を決定します。

復旧手順を確立する: 各サービスやコンポーネントの復旧手順を定義し、復旧に必要な手順と依存関係を明記します。

復旧プロセスを自動化する: 手動による介入を最小限に抑え、システムの復旧に必要な時間を短縮するため、可能な限り復旧プロセスの自動化を検討します。

復旧計画のテストと検証 :定期的にテストと検証を行い、効果的で最新の状態に保つようにします。復旧のための模擬演習を実施し、潜在的な問題を特定し、計画を改善します。

ディザスターリカバリテストが重要な理由

分散型システムにおけるリカバリーの課題

よく設計された分散システムでは、あるコンポーネントの故障がシステム全体の故障を意味することはないはずです。むしろ、故障はそのコンポーネント自体に分離されるべきです。このような種類の障害を適切に検出し、対応するようにシステムを設計することは可能である。いずれにせよ、災害復旧テスト計画は、現実的な条件が訓練されるように、これらのニュアンスを考慮する必要があります。ここでは、復旧可能な分散型システムを設計する際に対処しなければならない課題をいくつか紹介します:

ネットワーク障害とデータレプリケーション
ネットワークトポロジーは、通常の運用中に変化することがあります。ネットワーク・パーティション、ネットワークの混雑、ポリシー、ルール、セキュリティ・グループ、その他多くの要因によって、システム内のコンポーネント間で断続的または恒久的な切断が発生することがあります。

フェイルオーバー時のプライマリーネットワークとリカバリーネットワークをどのように設計し、運用しているか?また、本番システムと並行してどのようにテストを行うかを理解することも重要です。リカバリーシステムは、オンデマンドでリカバリーできることが分かっていればそれでいいのです。

分散トランザクション管理
分散システムで実行されるトランザクションは、複数のシステムにまたがる可能性があり、それらのシステム間で調整する必要があることを意味します。この調整は、複数のマシンプロセスにまたがるトランザクションを調整することになるため、些細なことではありません。

さらに、トランザクションは、それらの他のマシン上の他のトランザクションや、データベースやファイルシステムなどの外部リソースと調整する必要がある場合があります。

サービス依存性の解決
サービス間でビジネスロジックの実行やサービスコールを連携させるためには、サービス同士を見つけることができる必要があります。ほとんどのマイクロサービス実装では、サービスディスカバリーが必要ですが、モノリシックなアーキテクチャでも応用が可能です。

データの一貫性と回復
多くの場合、ディザスタリカバリは、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを回復することを目的としています。したがって、アプリケーションは、状態を失ったりデータを破損したりすることなく、障害から回復できるように設計されていなければなりません。

バックアップとディザスタリカバリの計画
バックアップは復旧計画に欠かせないもので、データのバックアップコピーがない場合は、ゼロから作り直すことも可能です。

災害復旧テスト + 復旧メカニズムの検証
リカバリープランは複雑なメカニズムに依存しており、本番環境に導入する前にテストが必要です。

ソフトウェアの新バージョンが常にリリースされ、リカバリに影響を与える可能性のある新機能が追加されるため、テストは定期的に行う必要があります。

N2WS vs. AWS Backup

復旧シナリオ : AWS環境でのデータ保護の構成管理ツール「 N2WS 」では、災害やAWSの停止が発生したときに実行できるシナリオを作成することができます。これにより、最も重要なリソースを重要度の高い順に復旧させ、RTO/RPOを最小化することができます。この機能のドライラン機能により、テストを実施し、これらの復旧を実行するための準備がすべて整っていることを確認することができます。

 

クロスリージョン/アカウントディザスターリカバリー :N2WSは、最も包括的なクロスアカウント/リージョンを提供し、ボタンをクリックするだけで全環境をリカバリーすることができます。AWS Backupのバージョンは非常に基本的で、実行が複雑です。

 

スケジュール :AWS Backupでは、バックアップのスケジュールを1/12/24時間ごとに設定するよう制限されています。N2WSではそのような制限はなく、バックアップは1分ごとにスケジュールすることができます。

 

ファイルレベルリカバリー  : AWS Backupは、Amazon EFSのファイルレベルリカバリーのみをサポートしています。N2WSは、EFS、EC2、S3に対してファイルレベルのリカバリを実行できます(暗号化されたボリュームに対しても)。

 

Start/Stop Servers (Resource Source Control) : N2WSのこの機能は、EC2インスタンスのアクティブ化と非アクティブ化のスケジュールを設定することが可能である。例えば、非生産用のインスタンスを月曜日から金曜日の午前9時に開始し、午後5時に停止するようにスケジュールすることができる。これにより、お客様はAWSのコストを数千ドル削減することができます。N2WSのお客様であるGett様は、この機能により年間60,000ドルのコスト削減を実現しています。

 

RDS MySQL & PostgresSQL (S3) : N2WSは、これらのRDSカテゴリをS3に保存することができ、より安価でコールド・ストレージを使用することにより、ストレージコストを大幅に節約することができます。AWS Backupにはこの機能はありません。

 

自動化 :  N2WSによる自動化のおかげで、お客様は他の重要なトピックにエネルギーを集中させることができ、N2WSにバックアップの世話をさせることができるようになります。つまり、一度必要なポリシーとスケジュールを作成すれば、あとはツールがバックグラウンドでバックアップを行い、何か問題が発生したり、注意が必要な場合はアラートが表示されるのです。N2WSは、保存ポリシーに応じて、S3、Deep Archive、Glacierなどのコールドストレージへの保存を自動化することも可能です。これにより、AWSのコストを大幅に削減することができます。

 

カスタマーサポート : N2WSは、24時間365日のプレミアムサポートを提供し、必要なときにはサポートします。AWSのサポートは別途費用がかかります。

 

レポートログとモニタリング : AWSでは、レポートログとモニタリングは別料金で、設定が必要です。N2WSでは、バックアップ、リストア、管理、監査の全活動を監視し、追加コストなしですぐに使えるレポートを提供します。

バックアップ対象(VM01, VM02)からVM02を除外した場合、VM02のリストアポイントは指定した世代数を保持しますか?

いいえ、保持しません。
例えば、リストアポイントを4世代とした場合、バックアップを取得するたびに世代数が減っていきます。
11/1, 11/2, 11/3, 11/4とバックアップを取得し、11/5にVM02が除外されたバックアップを取得した場合、VM02のリストアポイントは11/2, 11/3, 11/4となり、11/1のリストアポイントは消されます。
最終的には11/4のリストアポイントがフルバックアップファイル内に残り続けます。
これを消すにはフルバックアップの再作成や再構成(Compact full)が必要です。

物理サーバのバックアップも行えますか。

はい、Veeam Backup & Replication Universalライセンスをご利用いただくことで、
仮想サーバに限らず、物理サーバも併せてバックアップ可能です。
Universalライセンスにつきましては、こちらをご参照ください。

Excelスプレッドシートから直接データの抽出できますか?

はい、Espressシリーズはデータ・レジストリー内でExcelデータソース機能を使用してExcelスプレッドシートから直接データの抽出が可能です。

 

 

詳しくはこちらのブログを参照ください。

Android端末に対応していますか?

はい、モバイル端末としてAndroid, iPad, iPhoneに対応しております。

Microsoft AzureやAWSなど自社利用のクラウド環境で稼働させることは出来ますか?

はい、可能です。

評価版から製品版データ移行することが出来ますか

はい、可能です。評価版システムに製品キー・ファイルを製品にディプロイすることで可能になります。

他システムとの連携は可能ですか?

外部システムとの連携用の備え付けのAPIを利用して外部システムとの連携が可能です。詳細はお問い合わせください。

操作講習会などはありますか?

定期的な講習はありませんが、導入検討中のお客様および購入済みのお客様向け無償オンライン講習会の準備は可能です。詳細はお問い合わせください。

導入前に評価することは可能ですか?

はい45日間無料で全機能ご利用可能です。評価は、クラウドでもオンプレミスでも選択いただけます。

詳細はお問合せページ

また無料でサポートを行っています。

システムの提供形態は何がありますか?

クラウド、オンプレミスのどちらでもご利用形態に合わせて提供が可能です。。詳細はお問い合わせください。

7. Database Performance Analyzer (DPA)でデータベースのチューニングはどのように行われるのですか?

Database Performance Analyzer (DPA)は、ユーザーがデータベースパフォーマンスの問題を監視、発見、解決できるように構築された、俊敏でスケーラブルなデータベースチューニングツールです。

 

DPAは、データベースアクティビティ、待機時間、SQLステートメント、アプリケーションリクエスト、およびその他のディメンションを相関させ、データベース速度低下の原因を正確に突き止めることができるように設計されています。 DPAでは、IBM DB2、SQL Server、SAP Adaptive Server Enterprise(SAP ASE)などの主要な商用データベースについて、SQLステートメントの迅速な分析、パフォーマンス問題の根本原因の特定、専門家のチューニングアドバイスを受けることも可能です。

6. データベースチューニングツールはどのように機能するのですか?

データベースチューニングツールは、通常データベースチューニングに時間がかかる手動プロセスの多くを自動化することによって、チューニングプロセスを容易にするように設計されています。

 

また、データベース・チューニング・ソフトウェアは、問題のある箇所を正確に把握できるため、クエリーやアプリケーションの中を探し回る必要がなく、効果的なトラブルシューティングの手段にもなります。見えない問題を解決することはできません。これらのツールは、データベースがどのように動作しているかを概観することができます

5. なぜデータベースのチューニングが重要なのか?

 

データベースクエリーの数ミリ秒の遅れは、あっという間に大きなボトルネックとなり、修正するのに長い時間がかかることがあります。データベースのチューニングが重要なのは、クエリの応答時間を数秒単位で短縮できるため、必要な情報を必要な場所にすばやく届けることができるからです。定期的なチューニングは、データベースパフォーマンスのベストプラクティスの重要な部分であり、アプリケーションのパフォーマンスを加速させる手っ取り早い方法となります。

4. データベースのチューニングはどのように行われるのでしょうか。

データベースのパフォーマンスチューニングのベストプラクティスに関して、ここでは簡単なチュートリアルを紹介します。

 

1)過去のデータを使って「正常」であることを確認し、データベースのベースラインに関する情報を収集します。ベースラインの指標を収集することで、データベースに何か異常があるかどうかを簡単に(そしてはるかに速く)確認することができます。

 

2)実行プランに目を通す。MySQL では、データベース管理者がクエリおよびデータベースのパフォーマンスを調査するためのさまざまな方法を提供しています。実行プランに目を通し、可能な限り効率的であることを確認します。

 

3)すべてのテーブル、インデックス、クエリに非効率性がないかを確認します。待ち時間の増加やインデックスのカラムアライメントを確認します。

 

4)ボトルネックを特定し、解消する。問題のあるSQLクエリとその原因を特定し、ボトルネックを解決する。

 

5)効果的な監視を実施する。非効率的なクエリは、データベースのパフォーマンス問題の主な原因であるため、データベースのチューニングの大部分はクエリパフォーマンスの監視に費やされます。たとえば、SolarWinds Database Performance Analyzerは待機ベースの分析機能を備えています。これは、時間関連の問題がデータベースパフォーマンスチューニングの最も顕著な問題点の1つであるためです。この方法は、データベースパフォーマンスチューニングの問題をより正確に切り分け、特定し、調査するのに役立ちます。

3. データベースのパフォーマンスを向上させるにはどうすればよいですか?

ここでは、データベース全体のパフォーマンスを向上させるために役立つヒントをいくつか紹介します。

 

●インデックスが論理的なデータ構造を実装していることを確認し、データ検索プロセスをより効率的にする。
●コンピューティングシステムのメモリーの予備を再割り当てする。十分なメモリがない場合、データベースはしばしば最も大きな打撃を受けます。
●MySQLやOracleの最新版を使用していますか? データベースを最新に保つだけで、データベースのパフォーマンスが向上することがあります。
●ループのコーディングや相関性のあるSQLサブクエリのような一般的なSQLインデックスの落とし穴を避ける。
●データをデフラグすることで、データベースのスピードアップにつながるかもしれません。十分なディスク容量があることを確認する。
●効果的なデータベースチューニングとパフォーマンス監視は、洞察とピンポイントでのパフォーマンス最適化の推奨事項を提供するのに役立ちます。

2.SQLパフォーマンスチューニングとは何ですか?

SQLパフォーマンス・チューニングは、データベース・パフォーマンス・チューニングと似ていますが、より狭い範囲に限定されます。SQLパフォーマンス・チューニングは、リレーショナル・データベースが可能な限り効率的に動作するように設計されたベストプラクティスや手順のことを指します。これには主に、SQLクエリーとインデックスのチューニング、管理、および最適化が含まれます。

 

定期的な SQL パフォーマンス・チューニングは、SQL パフォーマンス問題の一般的な原因である非効率的なインデックスと SQL クエリに取り組む費用対効果の高い方法であり、リソースを再割り当てしてシステムを自助努力で使用することによって実現できます

1.データベース・パフォーマンスチューニングとは?

データベース・パフォーマンスチューニングは、データベース管理者がデータベースを可能な限り効率的に実行する方法を指す広義用語です。DBMSチューニングは、通常、MySQLやOracleなどの一般的なデータベース管理システムのクエリをチューニングすることを指します。

 

データベースのチューニングは、全体的なパフォーマンスを向上させるために、データベースシステムを上から下まで、ソフトウェアからハードウェアまで、再最適化することを支援します。このチューニングには、最適な使用方法に応じたオペレーティングシステムの再構成、クラスタの展開、システム機能とエンドユーザー体験をサポートする最適なデータベース性能への取り組みが含まれます。

[初めに]このカテゴリーについて[Database Performance Analyzer (旧Ignite) について]

データベースのパフォーマンスモニター・分析ツール「Database Performance Analyzer(DPA)」についてよくある質問の一覧です。

 

本サイトはこちらです。