第59話で、イトはorigin serverを「元データを全部持つ一台の本館」だと決めなかった。
target resource、origin role、release ledger、storageを分け、primaryとsecondaryのresponse identityを残した。
二つのorigin applicationは、この学習fixtureではNorth facility zoneとSouth facility zoneに一つずつ置かれている。
イトがavailability boardを開くと、両zoneのrack lampはすべてcyanだった。
power A / B。
cooling A / B。
network A / B。
maintenance対象には、各B pathのamber keyが並ぶ。
イトはrack lampだけを見て、三本のkeyを一つのbatch holderへ入れた。
「serverは全部動いてる。予備のB側なら、まとめて止めても大丈夫」
closed simulatorで、power B distribution、cooling B loop、network B pathが同時にmaintenance isolationへ入った。
八秒間、rack lampはcyanのまま。
その直後、fixtureがutility power A interruptionを一件だけ注入した。
battery bridgeは始まった。
しかしavailable network pathは0。
cooling marginはamberへ落ちた。
single viewer checkはresponseを受け取れなかった。
rack lampは、まだcyanだった。
maintenance releaseまで、あと四十五秒。
rackが光っていても、serviceが生きているとは限らない
イトはcyan lampを数え直した。
ピコはrackへ触れず、utility entrance、power distribution、cooling loop、network entrance、service responseを別々に照らした。
イト
rackは全部greenなのに、どうしてresponseが来ないの？
ピコ
lampはrackの一部のstateだよ。requestが通り、熱と電力を支え、responseが戻るpathまでは証明していない
イト
Bが三つあるから、全部予備だと思った
ピコ
同じ文字より、どこを共有し、何のfailureから独立しているかを追おう
この話のfacility board、power、cooling、network、rack、request、failure injectionは、外部systemから切り離した学習fixtureだ。
実在facilityのswitch、valve、breaker、generator、fire system、access controlは操作しない。
live maintenance手順、電気工事、mechanical work、emergency response、Tier certification判定は扱わない。
見るのは、facility system、end-to-end path、shared component、remaining capacity、rollback、service outcomeの順序だ。
data centerは、computeを支えるfacility system
data centerは、server rackを収めたroomだけを指すものとして扱わない。
compute、storage、network equipmentを動かすには、継続したpower、heatを運ぶcooling、外部とつなぐnetwork、physical / environmental protection、monitoring、maintenanceが要る。
一つのequipmentが動いていても、依存先が失われればworkloadは利用できない場合がある。
逆に一つのserverが故障しても、workload placementとcapacityが適切ならserviceを続けられる場合がある。
facility healthとserver healthとapplication healthは、同じ一個のlampにまとめない。
今回のcyan rack lampは「fixture rack controllerが電力を受け、local checkへ応答した」だけを表す。
viewer requestが到達したか。
origin applicationがtarget responseを作ったか。
edgeへ戻れたか。
temperatureがfixture band内か。
別のsignalで確かめる。
powerは、plug一本ではない
power pathは、utility source、switchgear、UPS、generator、distribution、rack PDU、server power supply等の組合せになり得る。
実際のtopologyと名称はfacilityごとに違う。
UPSは瞬間的・短時間のbridgeやpower qualityを担い、generator等のalternate sourceが引き継ぐ設計もある。
「batteryがあるから長時間大丈夫」「generatorがあるから切替失敗はない」とは決めない。
fuel、starting、transfer、control、distribution、maintenance、capacityのどこが必要かをdiagramとtest recordへ戻る。
二台のUPSが同じupstream switchgearだけに依存していれば、そのshared componentのfailureを分離できない。
二本のrack feedが同じdownstream distributionへ戻っても、end-to-endでは独立していない。
予備の個数より、failure boundaryをまたいでpathが続くかを見る。
coolingは、冷たい風だけではない
serverは処理に伴ってheatを出す。
heatをequipmentから取り、roomやliquid loopを通し、facility外へ移す一連のpathが必要になる。
airflow、fan、pump、valve、chiller、cooling tower等のどれを使うかは設計によって違う。
NIST SP 800-53 Rev.5のPhysical and Environmental Protectionは、power equipment / cabling、emergency power、fire protection、environmental controls、water damage protection、physical access等を別のcontrolとして扱う。
PE-14 Environmental Controlsは、systemを置くfacilityのtemperature等を許容levelへ保ち、monitorするcontrolだ。
冷却機が「ON」でも、必要なspaceへflowが届くとは限らない。
sensorが一個cyanでも、hot spotや失ったloopを表せない場合がある。
temperature、humidity、flow、pressure等、設計で必要と決めたsignalを適切な場所で観察する。
fireとwater protectionもcoolingへ混ぜず、別のhazardとresponseとして設計する。
networkは、cableの本数よりpathを見る
fiberが二本あっても、同じconduit、same edge device、same power feed、same provider entryへ戻れば、共通failureで同時に失われ得る。
device diversity、provider diversity、physical route diversityは同じではない。
どこまで別pathかをend to endで追う。
facility内でswitchがgreenでも、external connectivity、routing、name resolution、application listenerのどこかでresponseは止まり得る。
network healthもrack lampへ代用させない。
今回のfixtureでは、network A / Bは別入口と別edge holderを持つ。
ただし最初のbatch maintenanceでBを閉じたため、A interruption時にavailable pathが0になった。
「二本ある」というinventoryと、「今二本とも使える」というstateを分ける。
redundancyは、名前ではなくfailure boundaryで分ける
AWS公式のAvailability Zones説明では、一つのAvailability Zoneをone or more discrete data centersとし、別AZ間でpower infrastructure、networking、connectivityを分け、generatorやcooling equipment等のcommon point of failureを共有しない設計例を示す。
これはAWS固有のlogical / physical boundaryだ。
どのdata centerにも同じ構成が自動で備わるという意味ではない。
大事なのは、separate locationの数だけを数えず、何のfailureをどこでisolateする設計かを明示することだ。
AWS Well-Architectedのmulti-location guidanceも、redundant componentがindependently operateすることを重視する。
theoreticalな冗長性は、componentが同じfailureで止まらず、surviving sideにloadを引き受けるcapacityがあって初めて役に立つ。
二台を同じrailへ寄せただけでは、shared fateを増やすこともある。
maintenanceできることと、故障に耐えることを分ける
maintenanceでは、componentやdistribution pathを意図して外す。
その間に別のfailureが起こる可能性も考える。
何を止めるか。
残るpathはどれか。
残るcapacityはpeak loadを受けられるか。
rollbackは何秒で、どのsignalを見て開始するか。
変更を一度に重ねると、どの操作でservice / environmentが変わったか分からなくなる。
Uptime Institute公式のTier Classification説明では、Tier IIIのperformance criterionをconcurrently maintainableとし、planned maintenanceでcapacity componentやdistribution pathを外してもoperationへimpactさせない考え方を示す。
これは認証されたsite infrastructureのcriterionだ。
本話のfixtureへTier labelを付けるものではない。
「maintenance中も止めない」という要求を使うなら、design document、constructed facility、operation procedure、actual workload placementを別々に確認する。
physical securityは、availabilityと人の安全にもつながる
入退室を制限し、誰がいつどこで作業したかを残す。
delivery / removalを管理する。
cableやemergency controlへのaccessを守る。
unauthorized actionを防ぐだけでなく、authorized maintenanceの対象取り違えや同時作業も減らす。
ただしcard readerがあるだけでphysical securityが完成するわけではない。
authorization、escort、monitoring、visitor record、key / credential lifecycle、emergency accessをfacility policyへ結ぶ。
fire alarmやwater leakでは、人の安全を優先するemergency procedureが通常maintenanceより上位になる。
alarmをservice continuityのために無視しない。
イトの前に、三つの選択肢が開く
maintenance releaseまで、あと二十五秒。
A cyanのrackを全部rebootする
request failureをserver problemと決め、facility pathを見ずにcomputeを再起動する。
working processまで止めるが、network Bとcooling Bは戻らない。
B B側equipmentを、動いているA railへまとめて接続する
lampの数はcyanへ戻せるかもしれない。
しかしA interruptionというsame failureへpower、cooling、networkを集め、独立性を失う。
C batch maintenanceを止め、approved baselineへ戻してから、一系統ずつ確かめる
facility diagramでpower / cooling / networkのshared componentとfailure boundaryを別々にtraceする。
surviving pathのcapacity、rollback trigger、service response、environmental signalを確認し、closed fixtureでsingle interruptionだけを入れる。
ピコはamber keyにもrollback holderにも触れなかった。
「rackを直す前に、rackを生かすpathと、利用者へ戻るpathをつなぎ直す」
イトはCを選んだ。
自分でthree-key batch holderを閉じ、approved fixture runbookに従ってpre-test baselineへ戻した。
power、cooling、networkのkeyを別holderへ分け、simultaneous maintenance countを0にした。
single interruptionで、残るpathを観察した
イトはcurrent diagramとfixture stateを照合した。
power A / Bは、test boundary内で別distribution holderへ続く。
cooling A / Bは、別pump holderとseparate control powerを持つ。
network A / Bは、別entranceと別edge holderへ続く。
surviving B pathのfixture capacityは、current test loadを上回る。
rollback cardはholderへ入った。
イトはsingle viewer GETを一枚だけ送った。
そのrequestを観察しながら、planned power A interruptionを一件だけ実行した。
power B path heldは1。
network B selectedは1。
cooling B fixture band内は1。
origin response status 200は1。
edge acceptedは1。
rack rebootは0。
simultaneous maintenanceは0。
rollback availableは1。
green lampを、end-to-end evidenceへ変える
イトはpower Aをapproved baselineへ戻し、path stateを再確認した。
その後のcooling maintenanceやnetwork maintenanceを、同じwindowへ重ねなかった。
次のtestは別のprecondition、owner、rollback、expected signalを持つ別eventにした。
rack lampはlocal healthの一つとして残す。
service responseは利用可能性の一つとして残す。
power state、temperature / flow、network selection、physical access recordも別々に残す。
一個のdashboardへ集めても、意味まで一個にしない。
facilityにredundancyがあっても、applicationが一つのzoneだけに置かれていれば、facility boundaryをまたいだservice continuityにはならない。
data replication、request routing、capacity、consistency、recoveryはworkload側でも設計する。
逆にcloud serviceを使っていても、providerが物理facilityを扱う範囲と、利用者がresource placementやbackupを選ぶ範囲は同じではない。
「data centerが強い」と「このserviceが止まらない」を飛び越えて結ばない。
rack roomではなく、止めないchainを残す
workbenchには、九つのevidenceが残った。
single viewer GET。
planned power A interruption one。
independent power B held one。
network B selected one。
cooling B within fixture band one。
origin 200 one。
edge accepted one。
rack reboot zero。
simultaneous maintenance zero。
data centerを「serverが並ぶ大きな部屋」と判断しない。最初にworkloadを支えるpower・cooling・network・physical / environmental controlのend-to-end pathを描く。予備機器の台数ではなく、shared componentとfailure boundary、maintenance中に残るcapacity、rollbackを確認し、一度に一系統だけclosed testする。rack lampが緑でも、service responseとenvironmental signalが失われていれば止まっている。
「守るのはrackの光じゃない。requestが通り、熱と電力を支え、responseが戻るchainなんだ」
イトはthree-key batch holderを棚へ戻さず、三つのseparate maintenance holderとsingle response cardの間に置いた。
facility diagramの上へ、半透明のresource poolが降りてきた。
physical rack、storage、networkの形はpoolの奥へ隠れ、手前には必要なcapacityを選ぶsmall control cardsだけが残る。
cloudは、誰かのserverを遠くから借りるだけなのだろうか。
次回：cloudは、遠くの貸しserver？
イトはphysical rack一台とcloud resource card一枚を同じ棚へ置こうとした。
「serverを自分で買わず、誰かのmachineを借りるのがcloudだよね」
ピコはrackへ触れず、resource pool、API control、shared responsibility boundaryを照らした。
次回、ピコルート第61話。
イトは、cloudを誰かのserverを借りるだけだと決めなかった｜何を選べる？