カテゴリー: インフラSE

ファイバチャネルボードの交換対応で作業確認漏れがあり、作業延期になりました。

キーワードになったのが「WWNの変化」です。

触れる機会が少なかったので失念してしまっていたので、

おさらいの意味で情報を整理してみたいと思います。

■WWNとは

https://ja.wikipedia.org/wiki/World_Wide_Name

World Wide Name（WWN）または World Wide Identifier（WWID）とは、ファイバーチャネルまたは Serial Attached SCSI によるストレージエリアネットワークにおける一意の識別子である。

上記ページにも書いてあるんですが、イーサネットでいうMACアドレスと似たようなものです。

■それで？

さっとググった感じ、こちらの記事が分かり良かったです。

伊藤忠テクノソリューションズ様のサイトより

https://www.ctc-g.co.jp/report/column/storage_se/vol08.htm

ストレージ概論～接続方式の多様化

FCスイッチで構成されたネットワーク環境だけを指してFabricという語もよく用いられます。

IPネットワークと同様に、データのルーティングを行うスイッチがサーバとストレージの間に介在しますが、これはFC-SANの場合にはFC-Switchと呼ばれます。

主な物理要素には、HBA(Host Bus Adaptor)、FCケーブル、FC-Switchがあります

3. FC-SAN(コンポーネント)

HBA – サーバにはFCケーブルのためのポートが準備されていないので、FCポートを有するHBAをサーバのスロットに挿入する必要があります。

5. FC-SAN (ゾーニング)

ゾーニングの設定のないFabricでは、そのFabricにつながれた全てのサーバとストレージ、およびストレージ内のボリュームが相互に丸見えの状態になってしまいます。

H/Wゾーニングとは、サーバとストレージが接続されているFCポートとFCポートの組み合わせで構成

サーバ側の情報(WWNN)とは全く無関係にゾーニングをしているので、サーバが入れ替わるかサーバ側のHBAが変更(=WWNNが変更)になった場合でもSAN環境としては影響がない

S/Wゾーニングとは、WWNの組み合わせで接続を制御

物理的な位置に依存しないという自由度がある反面、WWNが変わってしまう(HBAの交換など)とゾーニングの変更を行わない限りサーバとストレージの接続は確立できない

■つまり？

今回我々が陥ったのは

「HBA交換でゾーニング情報が変わった事による通信設定不良」

だったようです。

今回の環境ではFC-Switchはストレージ筐体内蔵のはずなので、

ストレージシステムの管理コンソールから設定する事になると推測されます。

同ストレージには別のサーバも繋がっているので、おいそれと変更も出来ませんが…

■今後の対応は・・・

手順を確認するか、ベンダSEに作業を依頼するか…

ちなみにこれ年末にリプレースする予定のハードなのです…

お金今掛けるのかよ・・・・・・・・・・

内作でやれと指示が出る気がしてなりません。

来週はベンダサポートとやり取りしまくる一週間になりそう。。

※以下の内容はあくまで個人の考えです。世間一般で正しいかどうかは知りません。

■要件定義書に必要な要素

・要件の一覧

まず何よりもこれ。顧客(ユーザの意味も含め)から挙がった要望がメイン。

どういった要件があったのか、見返せる必要があります。

（言った言わないを避ける為）

ベンダ側から提案するシステム化にまつわる課題も有りえます。

課題は切り出して一覧化する事も多いです。

・各要件の実現方式案と費用感

挙がった要件のシステム化を実現する為の手法。

複数ある場合も多々ある為、方式の比較検討を実施します。

費用については、「高額」「安価に抑えられる」の様なふんわりした言葉は×。

標準提供価格や過去事例等をベースに万円単位（対象システムの規模により変動）程度の概算。

金額は比較検討時の大きな要素です。

・システムやネットワーク等インフラ構成のイメージ

要件定義時点では「構成図」まで落とし込むのは無理です（後に続く基本設計でやる事です）。

だからといってシステム処理の流れやサーバ間通信の方法などを言葉で表現しても分かりにくいので、

言った言わないを含め認識の齟齬を避ける為にも大まかなイメージ図が必要です。

・タスクの公開と分担

どんなタスクがあって、顧客に何を求めるか、それが遅れるとどのように影響するか。

この辺りを共有しておく事はとても大事だと思います。

要件定義ならではのものではなく、プロジェクト一般に求められる要素ですね。

・一般的な非機能要件についての検討資料

この部分はネットを探せばいくらでも転がってると思います。

信頼性、可用性、性能、バックアップ、運用、あたりでしょうか。

代替業務手段はあるか、システム利用時間帯は何時か、同時処理数の想定は幾らか、バックアップが必要なデータは何か、定期的に必要な運用操作が無いか、etc…

新規システムの場合、運用については未知数の部分が多く悩みそうですね。

基本設計や詳細設計、システムテストでの実績から具体性を持たせて設計していくのもアリでしょう。

■要件定義のススメ方

①ヒアリング

顧客要件を洗い出し、システム化方式案を検討して、どのようにシステム化するかを定義する。

という作業の中身から考えれば当然ですが、ヒアリングからスタートです。

一般的な非機能要件であればヒアリングシートを事前に用意できるので、記入依頼するのもアリ。

ただ、顧客は現業遂行しながらなので、メールだけﾎﾟﾝと送ってもなかなか相手してくれなかったりします。

初期タスクの分担については、早い段階で一度打合せ開催するのが良いでしょう。

②実現案検討

これがベンダの腕の見せ所。知識が問われる部分です。

また、要件間の整合性や制限事項にも注意が必要な為、経験が活きる部分でもあります。

例えば、ある要件の最善策が、別要件の制約事項に抵触する場合があったりします。

そのため、各案を急いで確定する必要はないと思いますが、顧客のイメージをブラッシュアップしていく為に、ある程度の塊・間隔で説明会など内容共有の場を設けるのがよいでしょう。

検討中に顧客から情報を引き出す必要性（端的に言えば質問）が生じる事も多々あります。

都度質問にするか、質疑内容をまとめておいて質問会を設けるか、やり方は様々です。

どちらもメリット・デメリットがありますし、顧客の好みもあるでしょう。

進め方については顧客と相談して合意するのが定番かと思います。

③レビューと承認

全体が出揃って整合性などを確認した上で、内容を顧客へ説明し承認頂きます。

全部をまとめて一度に、というのは時間的にも難しいと思いますので、小さな単位での承認を何度も繰り返す事になると思います。

実現方式の案毎、各要件のカテゴリ毎、ドキュメントの章立て毎など、いろんな単位が考えられます。

④要件定義内容の整理

取り決めがキチンと資料としてまとめられている事が最低要件です。

ドキュメントレビューの形で承認を得たのであれば、体裁は完成しているでしょう。

また、要件の一覧に最終結論を反映しておく必要もあると思います。

（検討結果で要件から外れる事も結構な割合で起こりますし、やる筈と思ってたという認識の齟齬も同じくらいの割合で起こります）

それに加えて、基本設計時に必要な情報にアクセスしやすいよう、インデックスを作成しておくのもオススメです。

要件の発生はいつもカテゴリ単位に纏まってる訳でもありませんが、設計はカテゴリ単位に行うのが一般的だと思いますので、識別情報があると便利です。

「あの話結論どうなったっけ」みたいな内容を探し回らなくて済むよう、状況もまとめておくとよいでしょう。

今週は会議や調査ばかりで技術的な業務があまり発生しませんでしたので、思いつくままに書いてみました。

正直大した経験はないので、甘い部分や間違いもあるかも知れません…

■Windowsの共有フォルダをマウントする

コマンド一発です

mount -t drvfs //ターゲットホスト/共有名 マウントポイント -o rw,username=ユーザ名,password=パスワード,iocharset=utf8

ちゃんと共有側の書き込み権限を設定しておかないと、パーミッションが777に見えても書き込めません。

■SSHサーバを立てる（＆Win側からTeraTermで接続）

こちらはちょっと試行錯誤がありました。

１．起動を試す

/etc/init.d/ssh start

ホストキーがないとの事。keygenしてないし当然でした。

２．まずは設定ファイル確認

cat /etc/ssh/sshd_config | grep Host

全部コメント化されてました。とりあえずrsaだけコメント解除。

３．キー生成

sshd_configに定義されていた名前でキーを生成。

cd /etc/ssh
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ”

４．再度起動確認

/etc/ssh# /etc/init.d/ssh start

今度は起動しました。

５．TeraTermでクライアント側鍵生成

[設定]＞[SSH鍵生成]

RSAで生成した場合、id_rsa,id_rsa.pub　がTERATERMのインストールフォルダに生成されます

６．公開鍵をサーバに転送

FTPサーバは起動していなかったので、ファイルコピーで。

Windows側からWSLのパーティションを見る方法がすぐにわからなかったのですが、

WSL側からは各ドライブが/mntにマウントされている事がわかっていたので、

WSLからWindowsのファイルをとってくることに。

su – WSLユーザ
mkdir .ssh
cd .ssh
cp -p /mnt/ファイルパス ./

とってきたid_rsa.pubの中身を、忘れずにAuthorized_keysへ追記

cat id_rsa.pub >> authorized_keys

上書きにはくれぐれもご注意を。

７．TeraTermで公開鍵認証でログイン

鍵ファイルを指定してチャレンジ。無事にログイン出来ました。

sshd_config では以下の２つがデフォルトで無効になってました。

PasswordAuthentication
ChallengeResponseAuthentication

勿論これを変更すれば公開鍵以外の方法でもログインできます。

設定を変更したらサーバのrestartを忘れずに！

これを書いてるお前のことだぞ！

WSFC+SANディスク共有で冗長化してるサーバの保守期限が迫ってきました。

JP1/AJSでバリバリに業務ジョブが動いてるので、故障したら社内業務がﾊﾞﾂﾝと停止します。

先月気づいてから対応策を検討していたのですが、

色々な思惑や予算の兼ね合いもあって調整が難航。

だんだん手が無くなってきてしまい、久しぶりに師匠に泣きついてみました。

そこで紹介されたのが件のソフト。

■ミラーディスク型HAクラスタ

この言葉自体初めて聞いたので、ググってみました。

が、CLUSTERPROの記事ばっかりヒットします。

そもそも一般的な構成ではないのかな？と調べてみました。

要は

「クラスタ構成サーバ同士のローカルディスクをRAID1(ミラーリング)で構成する」

という考え方みたいでした。

ファイル共有で公開するディスク領域を使ってHAクラスタ組めないかな？

と考えてたので、これが出来るなら願ったり叶ったりです。

詳しくは、NECの製品オフィシャルブログを見て頂いた方が良いでしょう。

CLUSTERPRO オフィシャルブログ ～クラブロ～

HAクラスター入門 ～用語解説2～

■今回検討した事

他所様のブログ記事を紹介して終わるのも味気ないので、

備忘録として検討内容についても残しておこうと思います。

①Azureへ環境移行

当初は一番安定と思っていた案。安く早く環境を準備出来るだろうと。

ですが、結構な頻度で障害が起こる事、サーバ停止が社内業務停止に直結する事、

あと通信間隔が数秒程度の処理がある為遅延が許容範囲を超える可能性がある、

といった部分のデメリットが大きすぎるとの事で廃案に。

②リプレースプロジェクト（後述）にて機器だけ先に購入してもらう

テストサーバ兼パイロット機をレンタルする予定、と小耳に挟んだので、

それならいっそ購入して貰えないか、それを少し早めにしてもらって、

本番機として使う部分と両立出来ないか、と強請ってみました。

これはまあ通ればラッキーぐらいのつもりで出した案でしたし、一蹴されました。

③同モデルの別サーバ(廃却予定)を予備機とし、故障時はスポットで保守対応を依頼する

本件に気付いた瞬間に「まず全く今のままの状態だったら何が出来るのか」と考えた時の案。

結構イイ線だとは思っていたのですが、FC接続用ボードの挿し替えがハードル高そうです…

無茶ながらも②よりは実施可能な案だとは思うのですけれど。

④クラスタは諦めて２台の余剰サーバでJP1/AJSのマネージャ・エージェントを新規構築

最終的にこの案になりつつあります。

ですが、「死んだら終わり」の状態で胸を張って「無事移行しました！」とは言いづらく（笑）

なんとか可用性を高められないかと頭を悩ませた末、泣きついた次第です。

■そもそも

サーバ移行が延び延びになっていて、しかも裏ではリプレースプロジェクトが動いている。

（全社を挙げて取組中の、国内拠点全てを巻き込む本当に大規模なシステム刷新）

そんな状況を聞いて、この作業ほんとうにやる必要あるんですか？と問うてみたのです。

課長の「リプレースプロジェクトに任せといたらええねん」を鵜呑みにしてしまって、

よくよく確認したら保守切れからリプレースPJの本番まで１年空いてました。

半年前の自分を半年くらい問い詰めたいですね・・・

しばらくの間休日出勤やら翌週準備に追われて更新出来ませんでした。

コロナ怖いですね、怖いですがオンプレ環境の運用となるとリモートワークが中々許可下りません。

さて、そんな中弊社、というか出向先の企業（本体1万人オーバーの結構な規模）では、

社内システムの大規模刷新プロジェクトが進んでいるそうです。

進んでいる、と話には聞くのですが。実際関係者はかなり忙しそうなのですが。

インフラを検討する要員は居ないそうです。ふむふむ。大変な事になりそうですね。

って他人事と思ってたら、現行システム運用に携わるメンバー、つまり私なんですが、

「この拠点のシステムの未来像を検討してくれないか？」というぼやかしたお言葉で、

お仕事が回ってきてしまいました。

未来像って、刷新後の環境が前提ですよね…

とはいえ普通に要件定義や設計をしてしまうのは契約範囲を超えるので、

プロパーの若者を主役に、私は補佐として関わる事になりました。

まずは経緯を知るために去年のトレンドがどうだったのか、と調べてみました。

いくつか読んでみて、端的でわかりやすいと思ったのが下の記事。

今後の企業におけるインフラ＆オペレーションに影響を与える10のトレンド

＠ＩＴさんは定番という感じですね。昔から随分お世話になっています。

先日ご紹介した芦屋広太氏のコラムを知ったのも＠ITさんだったと思います。

特に目を引いたのが記事冒頭の一文。

　「インフラ＆オペレーション（I＆O）で肝心なのは、もはやハードウェアやソフトウェアではない。ビジネスニーズを満たすサービスを提供することが肝心だ。インフラの未来がどこにあるかについては、あらゆる可能性がある。それを決めるのは、ビジネスでインフラをどう使うかだ」（ウィンザー氏）

私みたいな古い人間は、それこそメモリは640KBの時代を生きてきたので、

”インフラといえばハードウェア”みたいな感覚なのですが。

若者世代にとってのインフラとはどのようなものになるのでしょうね。

ネットワーク同様、実体の見えづらいベールにくるまれた何か。

何がどうなって出来上がる”モノ”なのかを意識する事なく、”何が出来る”という視点で、

サービスのように見えるのでしょうかね。

水のように、電気のように、本当は何か誰かが供給してくれているのだけど、

当たり前のように提供されるサービス。

本当の意味での”インフラ”になっていくのかも知れません。

さて、話を戻してインフラ、この先。

前述の記事中で、現在の職場にすぐ効きそうな（というか取り組み中の）ポイントを一つ。

それが、「トレンド6：デジタルダイバーシティの管理」の中で課題として挙げられている、

“分析まひ”からの脱却、正確なインベントリの維持、可視化不足による膨大な無駄の回避、資産管理

ですね。

忙しい事を理由に管理をサボる事で、更なる忙しさを招くサイクルの原点ですね。

ウェブサイトのブックマーク整理に似ていると思います。

ブックマークする時に、単にお気に入りに追加するのか、分類をその時に考えるのか、

既に分類された領域に登録するのか、ブラウザのブックマーク機能に頼らず別管理するのか、

やり方は色々あると思います。

ただ、一旦適当に扱った情報を後から整理するのは非常に非常に非常にコストが掛かるものです。

これはどなたも経験があると思います。

その為、これはこうやって管理しよう、とそれぞれに知恵を絞る訳ですし、

整理術の本がたくさん売れる訳です。

話が逸れそうなので元に戻しますと。

きちんと情報を管理出来ない事が様々な無駄を招き、

それが「情報を必要とする際の行動コスト」に跳ね返る。

場合によっては、情報の見落としによるトラブルへと発展する。

だからこそ軽視してはならない管理項目なんだと思います。

ここで何より大事だと感じるのが”決めたルール通りに行動するかどうか”です。

結局色々な管理基準を定めて運用を初めても、忙しさを理由にサボってしまっては、

全く何も意味がなくなってしまいますので。

日本人は謹厳実直、と表現されるのをよく見ますが、それなのに何故こんなことに？

答えは簡単だと思っているのですが、日本人は謹厳実直なのではなくて、

人の目を気にして見かけをつくろっているのでしょう。

だから、人の目につかない所で手を抜いたりいい加減な事をする。

縁の下の管理業務の杜撰さに、そういった側面が現れているのではないでしょうか。

未来を考えるよりも、足元をちゃんと固めるべきではないか。

そんな風に感じた「インフラ、この先」考察でした。

『プログラマーは延々プログラムだけ書いてるから人と喋らなくていい仕事』

みたいなイメージって、風聞としては耳にしたことがありますけど。

現実にそう思ってる人って居るんでしょうか。

確かに、ほぼ語らずに与えられた仕様に沿って、

黙々とコーディングしてる方もいらっしゃいますので、

そういう人がいない訳でもないですが。

仕様書だけ渡されて会話というか対話せずに仕事が完結する、

って事、有り得るのでしょうか。

完璧な仕様書とそれを作れる現場を知らないだけで、

大昔にウィザードと呼ばれたような人達が跳梁跋扈する最前線では

そういう仕事が当たり前なのでしょうか…

書きながら何となく自分の住んでる場所がぬるま湯なのかと

不安感が首をもたげてきたのですが。

別に明日明後日に住処を変えるでもなし、忘れようと思います。

言いたかったのは、仕事するのにコミュニケーション能力って大事で、

別にプログラマだからって変わらないよ！って事です。

前述したような完璧な仕様書でなければ、

製造の最中に実装について「どうあるのが正解なのか？」と

疑問が湧く事が多々あると思います。

他者は分かりませんが、私はありました。多々。

納得出来てコードに落とせるまで、

設計したSEを捕まえて延々対話してました。

コードをどのように書くか、はプログラマの力で成す事で、

コードが動いた結果がどうなる(べき)か、は設計者が決める事、

だと言う事がよく判っていなかったプログラマ時代。

忙しいSEさんに延々相手してもらう事をとても申し訳なく思ってました。

今なら「こんな適当な設計で何を作るつもり？」と突き返してますね。

そんな当時一緒の現場に居た開発者に、

「仕様書に書いてない事は何もしません」

というスタンスの方が居られました。

あのぐらい割り切れるのはすごいなと思ってました。

仕様書の内容が矛盾しててもそのまま実装して、

テストでおかしな結果になっても「仕様通り」と言い張る。

確かに仰る通りなんですけど、それで良い訳ないよね？

とSEが指摘しても

「設計を勝手に変えるのは良いんですか」と宣う。

ダメに決まってるけど、仰る通りなんですけど。

なんで「不備の仕様を放置する」か「仕様を勝手に変更する」の二択なの。

何かおかしいよ？どこ？これ。ふんふんそういうケースもあるのか。

って、５分くらいの対話で事足りる事なのに…

開発者が設計者に不備を伝えるのも、管理者が問題点を拾いあげるのも、

設計者が不要な仕様変更を怒らせずに断るのも、

コミュニケーション能力の側面なんだろうなと思います。

本当に言いたい事をうまく伝える。相手の言い分をうまく理解する。

どちらもとても難易度の高い事ではありますが。

よいコミュニケーションは仕事をうまく進めてくれて、

その時は大変でも最後には丸く収めてくれる、と感じます。

これらはいわゆる「ヒューマンスキル」と呼ばれるものですが、

若い頃にとても参考にしていたのが、＠ITというサイトで連載されていた

芦屋広太氏のコラムでした。

メールの書き方から、対話シナリオの考え方、物事の伝え方、

いろんな観点で芦屋氏の影響を受けたと思います。

古いコラムなので今読めるか分からないのですが、

こちらの書籍が同ジャンルの内容でしたので、オススメしたいと思います。

ビジネス文章クリニック 気になる「症状」治します！ [ 芦屋広太 ] 価格：1980円（税込、送料無料) (2020/3/28時点) 楽天で購入

今の現場は７時５５分出社で、なかなか朝がツライです。

毎日眠くて眠くてたまに寝過ごしながら業務に勤しんでおります。

さてメシのタネですね。。。

私自身は、良くも悪くも思うままに仕事をしています。

一応リピート案件も多いので、クライアントもサービス提供先も、

一定の満足は得て頂いているのだと思います。

ここ数年は、サービス提供先企業のIT担当者から

直接御連絡を頂く事も増えてきており、

ただただありがたいの一言ですね。。。

ともあれ、当たり前の事しかやってないのですが、

こんな高卒SE（※いきさつ）でも食っていけてるのは、

あるプロジェクトのマネージャに言われた事が、

一つのポイントなのかなと感じています。

「○○さん(=わたし)は、グレーゾーンをきっちり埋めてくれるよね」

当たり前の事しかしてないつもりなんですけどね。

分業体制という今の世の仕組がうまく自分にマッチしてるのかも知れません。

分業すれば当然自分の範囲という区切りが出来ますが、

それはあくまで「全体の一部」なのであり、

前後、最初から最後、がキチィンと繫がっていなければなりません。

こういった「全体の一部」を作っている時に生じる

疑問、不明点、そういったものを

「明示されてないから好きなようにしていい」

と考えるのか

「明文化されていない件のコンセンサスを得る必要がある」

と考えるのか、そしてそれを

「偉い人がまとめる事（であって自分の仕事ではない）」

と考えるのか。

人それぞれでしょうけど、私はそれがハッキリしていないとイヤなタチで、

こういう事で合ってるよね？こういう認識でお互い揃ってるよね？

などと、ほうぼうに聞き回る事になります。

・判っているけど自分の仕事じゃないから言わなかった、

・このままならトラブるのは当たり前だと思ってた、

みたいに嘯く人もぼちぼち見かけるのですが。

そんなにIT業界には仕事が溢れてるのでしょうか。

私は常に自分が今後も仕事が頂けるか不安で不安で・・・

分のやるべき範囲はここからここまでなのだから、

範囲外の仕事は（たとえ全体がどうなろうと）やりません、

みたいな態度で、次も仕事もらえるような気がしません。

プロジェクトが成功して、満足頂けて、

それで初めて我々SEのやる事に価値が生まれるのだ、

と考えていますし。

そもそもIT部門って、システムの導入効果が見えないと、

ただお金食うだけの部署ですしね。

仕事（≒プロジェクト）が問題なく終わるために、

それだけの仕事でいいのか？

って事です。

自分の仕事が自分の満足いくレベルに達する為に、必要な事はすべてやる。

それが、私にとっての「当たり前の仕事」だったというだけです。

余計な事までやる意味が一体何があるんだ、

と思う方も居るかも知れませんが。