AI-cafe

RAIDとは複数のハードディスクで論理的に１つのディスク（領域）と認識させる技術。ディスクへの書き込み・読み込みを高速化したり、構成しているディスク故障時にもデータロストとならない冗長化が構築できる。 最近の共有ディスク装置においては、大きなキャッシュメモリを搭載しており、ＲＡＩＤディスク構成や本数の性能差はあまり感じられない場合もある。 またディスク故障時、二重障害でない限り、RAID構成に組み込まれていない予備ディスクを設定しておき自動的に組み込むことで、縮退状態で運用するケースも回避できる。 I/Oや用途を考慮しRAID構成を別にしたり、同構成内に空き容量を大きく取るなどの工夫も大切な要素だ。 ハードウェアRAIDはシステムボードのオンボードRAIDや、RAIDカードを用いた構築方法で、ソフトウェアRAIDとは、OSなどのソフトウェアからRAIDを構築する。 ●メリットとデメリット ソフトウェアRAIDは、CPUにRAIDを制御するための負荷がかかるので、パフォーマンスを低下させる原因にもなる。 ハードウェアRAIDはマザーボードがRAIDに対応しているか、またはRAIDカード構築する必要がある。 OSに依存しないで、RAID構築することができ、CPUパフォーマンスにも影響を与えない点（少ない）に大きなメリットがある。

UNIX 関連の シスログ が文字化けする場合がある。 1，OSインス トール 後にシステムの 文字コード を変えた。 2，アプリケーションのインス トール した時の 文字コード がちがう。 影響を受けるのが2バイト文字のメッセージが多い。英数のメッセージは問題なく出力されている場合がある。構築時の手順を考える際、変更の前後関係を考慮が必要だ。 1行全てが文字化けの場合は、出力元のアプリケーションが原因の場合が多い、タイムスタンプは正常であるが、一部の文字化けの場合は、アプリケーションだけでなく、OSの状態や文字コードの関係性も確認が必要だ。一行全てといってもメッセージが2バイト文字であることが前提となるが。

ネットワークスイッチを学ぶ前に　LINUXのIPTABLEを復習しておこう。 iptables iptablesは、Linuxに実装されたパケットフィルタリングおよびネットワークアドレス変換 (NAT) 機能。ファイアウォールやルータとしての役割を果たす。 iptablesの構成 iptablesでは、フィルタリングする対象を選ぶ「テーブル」と、各テーブルにおいて、どのタイミングで処理するかを示す「チェイン」で構成されている。 filterテーブルはパケットのイン・アウトを制御できる。 natテーブルはパケットの中身を書き換えることを制御でき、主にネットワークアドレス変換に用いられる。 filterテーブルでは、次のチェインが代表的。 パケットが入る際に利用するINPUTチェイン パケットが出ていく際に利用するOUTPUTチェイン インターフェース間を経由する際に利用するFORWARDチェイン natテーブルでは、主にパケットを書換える変換ルールが記載されている。 ランニングコンフィグとスタートアップコンフィグ 現在の設定内容を「ランニングコンフィグ」（running-config）と呼ぶ。 ランニングコンフィグの内容は設定コマンドの入力とともに変更され、通常はただちに動作に反映されますが、ランニングコンフィグはランタイムメモリー上にあるため、システムを再起動すると消えてしまう。 ランニングコンフィグを保存しておきたい場合は、任意のファイルに書き出す。 書き出し先を「スタートアップコンフィグ」（startup-config）ファイルにしておけば、次回起動時に現在の設定内容（ランニングコンフィグ）が自動的に復元されるようになる。 この2つのファイルの関係性は、ネットワーク機器のベンダーを超えて共通の場合が 多い。呼び名やコマンドに違いはありますが。

うるう秒。あるタイミングで1秒挿入されるわけだが、システムの障害もいくつか発生した。2017年1月にもあったが大きなニュースになることはなかったと感じている。 コンピュータシステムはNTPというサービスでサーバや機器の時刻を同期している（場合が多い）が設定自体は意外とシンプルであるが仕様や仕組みは意外と奥が深い。放送局の時報と同期するデバイスのある。ネットワークの接続に制限が有る場合に利用されていた。（外部ネットワークへの接続に対する制限） システムの時間は、一度進んでしまった時刻を戻すのはむつかしい。 データベースやログなどシステム時間を参照しつつ独自に時間をもっていいる。そのソフトウェアやサービスは、時間が進んでいるからといって簡単にもどせないものもある。あるあるです。どうぜ時間がくるうなら遅れてほしい。進めるのは問題が起こりづらいからだ。ここには、一時期流行った「マーフィーの法則」が働く場合が多い（笑）。

サーバトラブルが発生した、復旧のため状態を確認する。 リモートログイン。ネットワークの状態。ログのメッセージ。プロセスの状態。ディスクの状態。ダンプの有無。切り分けて原因を追究していく。 確認したら一息つこう。第三者に伝えよう。いきなり対応をしだすとさらに悪化させる場合がある。また原因を判定する状態を戻してしまう、消してしまう場合がある。慌てて確認していると見落とす場合もある。 落ち着いて。慌てない。1分1秒を争う場合もある。そんな時こそ。落ち着いていこう。こんな時の原因は、意外とシンプルな原因で発生している。当たり前から疑っていこう。 コロナウィルスでパンデミックそして緊急事態宣言。こんな時こそ仕事で培ったノウハウを。「正確な情報に基づいて、落ち着いて行動する。」

朝の通勤電車。相変わらず満員だ。扉の前に立ったので次の駅で乗降の妨げにならないようにホームに降りた。 乗車のために白線の内側に並んでいた先頭の婦人が、車両に近づいてきた。私の背中をぐいぐいと押してきた。「邪魔だ、どけ」と言わんばかりだ。なんとか乗車すると、その婦人は一言も発せず、さらに周りの人を押し分け、吊り革につかまる人の前に強引に割り込んだ。乗車口近くではスマホ操作の青年と吊り革につかまるサラリーマンの肘がせめぎ合いをしていた、青年のクビは右に曲がりつつもスマホ操作をしていた。また別の場所ではスマホでゲームしている若いサラリーマンが隣のサラリーマンの圧力に舌打ちと小さな声でボヤいていた。「黄塵万丈」と例えていいだろうか。同時にだ。

2020年3月　ZOOMに脆弱性。これから同様の問題が発生するはず。注意が必要だ。複数の手段を用意しておかないとカバーできない。ZOOMの特徴は、会議参加者は、インストールは必要だが登録は不要である点だ。開催者でなく参加者においてだ。よってそこにおいては個人情報はないことになる。 対応は完了しているが、可能性として何が危険なのか掌握して利用すべき、そのアプリが脆弱だからとアカウントがのっとられて社内情報が流出するのか、そのアプリを利用した通信情報が第三者に漏れる可能性があるのか。等。 テレワークがこれから本格対応していく4月初旬、新しい角度の障害が発生すると思う。課題がなければ成長できない。一通りのトラブルや障害をあぶりだして安定した技術が確立される。コロナウィルスとリモート接続の脆弱性、両方同時に取り組む必要がある。 バグというより、設計ポリシーがよくなかった、等の修正がされた。問題点を公にして修正されたソフトウェアは、ある意味信頼ができると思う。勝手に他のサービスと連携とかはいただけなかった。あらかじめ全面に強力に周知しておけばまだしも。今はシェアNo、1なのでその信頼を育ててはしい。