ハードウェアを知る (5) ハードディスク (2) RAID

もう皆さんは RAID 組むことはないかもしれないですねぇ… Cloud の IaaS でも組んでいる話を聞いた事が無いので。
ただ、データの冗長化を考える上で良い素材ですし。オンプレミスは無くならないので、是非知っておいてくださいね。

RAID とは

RAID (呼称 - レイド) は、元の英語が2つあるんですよね。
Redundant Arrays of Inexpensive Disks、または Redundant Arrays of Independent Disks

RAID - Wikipedia 

ディスクの冗長化の仕組みです。データを保護するためのものですね。HDDはモーターで回りますから。壊れますよね。

で、その理解には例を見る方が理解が早いと思います。
RAID は、その方式を数字で分類しています。私が好きなのは、 RAID-10 (テン)。1 と 0 の両方を併せ持った最強の構成です😎。

RAID-3以外をここでは見ていきます。

RAID-0 : ストライピング

下図の上に、RAIDの構成を選択する際の主な指標であるパフォーマンスと冗長性について記載しています。それ以外に費用もありますが😊 費用は大事ですよ。壊れるんですから。その費用もばかになりませんよ。

RAID-0 では、データを使えるだけのDisk 数だけ分割します。つまり、一度に読み書きをするデータのサイズが小さくなります。これ大事ですよね!

書き込み処理を行うと、下図の様に (上と若干違います)、それぞれの Disk にデータを分割して一度に一気に書き込みます。読み取りも同様ですね。

これ、コンピューターの中で一番低速なHDDを同時に使えるので、パフォーマンスが結構リニアに改善します。つまりDiskは2つ以上必要ですね。そりゃそうです😊

欠点は、1つでもDiskが使えなくなると、データが損失する事です。

RAID-1 : ミラーリング

RAID-1 では、データの損失を限りなく0に近づけるため、データを2か所に書き込みます。

下図のように、データを2つのDiskに書き込みます。

RAID-1も、Diskが2つないと構成できませんね。
パフォーマンスは、実はDiskが1つの時と変わらないです。複数Diskへの書き込みの制御を考えると、微妙に遅くなっているかもしれません。

RAID-5 : パリティの登場

RAID-0とRAID-1は、冗長性とパフォーマンスで、両立が難しいわけです。
そこで、データの整合性をパリティという形でとって、その冗長性とパフォーマンスのバランスよくとろうと狙ったのが RAID-5 です。

パリティというのは、データの整合性のチェックをする仕組みです。誤り検知ですね。よくあるのは、データは2進数で表現されているので、その0もしくは1のどちらかが、奇数個なのか、あるいは偶数個なのかを算出して、それをパリティデータとして別に保存をしておきます。

パリティビット - Wikipedia

RAID-5 では、既存データからパリティデータを作成します。上の図の1-3までで、一塊として。それらからパリティデータを作成する、というわけですね。
そして、それぞれのデータを別のDiskに書き込みます。

これによってですが。

例えば Disk 1 が使えなくなっても、残りの2と3データとパリティから、1を算出できるんです。
じゃ、パリティの入った Disk 4 が壊れたら? 元の1-3から、パリティデータを作成できますよね😊

RAID-5 で冗長性は高まります。しかもミラーリングと違って、Diskの本数も抑えられます。
ところが、パリティ用データを作成する時間と、そのデータの読み書きを行う時間がオーバーヘッドになりました。つまりパフォーマンスは若干悪くなるんです。

RAID-10 : ストライピング + ミラーリング

繰り返しですが、私のイチオシ!😍
RAID-10は、よく RAID-1+0という表現もします。

RAID-10 では、ストライピングとミラーリングを同時に行います。つまり、冗長性とパフォーマンスを兼ね備えているんです! ステキですよね!

パリティの計算不要。
1つが壊れても、即座にバックアップがある!

じゃ欠点は?
実は絵を見たら即座に理解できると思います。Diskの本数が最大。最小で4つからですかね。つまり、もっとも費用が発生します😅

ストレージシステムのパフォーマンス改善の要点

これ、若干古いかもしれませんが、原則は今も変わってまいせん。

まずは、アーキテクチャを理解しましょう。どこから、どこへ、どうデータが運ばれているのか? PC内部のアーキテクチャと同じです。

上記で私がオンプレミスのシステムで幾度も目にしているのが、以下です。

• アプリケーションの設計

• (その結果) 特定の物理ディスクへのトランザクションの集中

それ以外はストレージのエンジニアに「既存のアプリも変えられないし、ハードウェアもあるもので何とかしないとけない。何とかならない?」と診てもらう場合のチェックポイントですね。

まず監視をしていて、読み書きが遅い! と判明します。その際に、特定の物理ディスクの性能を見ます。RAIDの構成が話題になることもあります。
ですが、それは、ハードウェアが好きな人だけの話。実際には、その原因の殆ど。というか私が遭遇したものは100%、アプリケーションの設計に原因があります。

改善例を挙げます。
RAIDの見てもらえれば、最後は RAID-10にしてますよね😎

s

アプリケーションの見直しの例 - SQL Server の構成(だけ)

前にも触れましたが、激しい IO を求めらるシステムは、皆さんのアプリが動く Web Serverじゃないんです。データベースやHadoop/Spark のシステムです。
SQL Server や MySQL などのデータベースのアプリケーションは、Diskを何本使えるのか知りませんよね。だからデフォルトのまま使っちゃ、その性能は活かせないです。
まず、OSから見える範囲に限定がされます。ここ大事で、大量のDiskをコンピューターに追加しても、OSから見えないと意味がないんです。
で、OSにも32bit OSと 64bit OSがありました。今は殆どが64 Bit OS。そこで、OSから見える C Driveが、物理Diskのどこなのか?これはRAIDとの関連があるんです。
例えば、RAID-10で8本のDiskを組みます。これをOSからは1つの Drive と見えるようにして、D Drive にします。Windows の。Windows 上で動く SQL Server からは D:\data\pubs.mdf ファイル (このファイルパスはあくまで例で、適当です😊) にデータを書き込んでいます。SQL Serverは、どのDiskにデータを書いているかわかりません。Table を作成する人が、どの Disk にデータが書き込まれているのか、知っている必要があるんです!

さー、SQL Serverを例に、順にみて行きましょう。

SQL Serverの CREATE Table 文では、File Group という概念があります。

CREATE TABLE dbo.PurchaseOrderDetail
(
PurchaseOrderID int NOT NULL
REFERENCES Purchasing.PurchaseOrderHeader(PurchaseOrderID),
LineNumber smallint NOT NULL,
ProductID int NULL
REFERENCES Production.Product(ProductID),
UnitPrice money NULL,
OrderQty smallint NULL,
ReceivedQty float NULL,
RejectedQty float NULL,
DueDate datetime NULL,
rowguid uniqueidentifier ROWGUIDCOL NOT NULL
CONSTRAINT DF_PurchaseOrderDetail_rowguid DEFAULT (NEWID()),
ModifiedDate datetime NOT NULL
CONSTRAINT DF_PurchaseOrderDetail_ModifiedDate DEFAULT (GETDATE()),
LineTotal AS ((UnitPrice*OrderQty)),
StockedQty AS ((ReceivedQty-RejectedQty)),
CONSTRAINT PK_PurchaseOrderDetail_PurchaseOrderID_LineNumber
PRIMARY KEY CLUSTERED (PurchaseOrderID, LineNumber)
WITH (IGNORE_DUP_KEY = OFF)
)
ON PRIMARY;

最後の ON PRIMARY。これは PRIMARY という名前の File Group にテーブルを作成してくれ、という意味なんです。

CREATE TABLE (Transact-SQL) - SQL Server | Microsoft Docs

じゃ File Group はいつ作成するのか?
それは Database の作成時。

SQL Server の CREATE DATABASE の例です。

USE master;
GO
CREATE DATABASE Archive
ON
PRIMARY
(NAME = Arch1,
FILENAME = 'D:\SalesData\archdat1.mdf',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20),
( NAME = Arch2,
FILENAME = 'D:\SalesData\archdat2.ndf',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20),
( NAME = Arch3,
FILENAME = 'D:\SalesData\archdat3.ndf',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20)
LOG ON
(NAME = Archlog1,
FILENAME = 'D:\SalesData\archlog1.ldf',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20),
(NAME = Archlog2,
FILENAME = 'D:\SalesData\archlog2.ldf',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20) ;
GO

CREATE DATABASE (Transact-SQL) - SQL Server | Microsoft Docs

この Create Database 文では ON PRIMARY として、File Group を指定しています。
このCreate Database の例では、D Drive に複数のファイルを作成していますね。一つじゃなくて。

皆さんの DatabaseとTable。そしてデータを保存して持っているのは Indexもあります。Temporary DBもありますよね。
どうなっていますか?
同時に読み書きするDatabaseとTable/Index。それらとDiskの関連性は把握していますか?

まとめ

RAIDはハードウェアで出来る事を教えてくれます。そして、どうデータを分割すればお互いに処理ができるかも。
そして、ミラーリングをしていけば、ほぼリニアにパフォーマンスも向上します。Diskの本数を倍にすれば、パフォーマンスも倍に。ただ、いいところ4倍程度じゃないでしょうか?
一番改善するのは、アプリケーションです。ここでは SQL Serverの構成を例に出しましたが。

「じゃー、DBの構成を見直そう」

はい、それだと片手落ちです。というか、そのDBにアクセスしてくるアプリケーションの発行するSQL文に改善の余地があることが多いです。複数回SQL文を発行するような場合は特に。

ですが、いろんな選択肢を知っておくことが大事です。誰もが、アプリケーションに問題があるのは知っていても、実際の現場では、その改修が出来ない事もあります。

次回はSSDを軽めに取り扱おうと思っています😊