  |
はてなキーワード: マイグレーションとは
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
いくらRemixやらNext.jsやら最新鋭のフレームワーク使ってても、クソコードで書いたらクソが出来上がるだけだ。
つまり後入れ先出しが正しい、LIFO、ラストイン、ファーストアウト
だがちょっと待って欲しい、本当にそれが正しいのだろうか？
均等化する意味ある？
その時に颯爽と「下にふかふかタオルを隠してあるのよねーうふふ」と対処できるではないか
数日寝かしておけば繊維が再生するとか、無い
全体がヘタってきたタイミングで全とっかえすればよい、買い物は一回で済む
FIFOで毎日使ってる一部のタオルがヘタるとする、下の方はまだまだ健在
数枚のタオルを購入し一部廃棄
ヘタったタオルを見つけるたびに都度タオルをマイグレーションしなきゃならない
統計学的にはタオル購入回数は増える（人生全体で枚数と金額は変わらない）
考え方は色々あるよね
改めて考察、自問した次第
小遣い稼ぎでちょっとしたシステムを作ってたんだよね。DBのスキーマ定義とかマイグレーション履歴はgitにチェックインしてあったし、コード読めない人のためにそこからER図も自動出力するように設定していた。
ある日、おじさんが急に上にやってきて「DB定義はエクセルでやるのが業界の常識！そんなことも知らんのか！」と言ってきたんだよね。このおじさんの経歴を見てみるとまともな会社で働いたことが一度も無い。学生時代に受託のシステム会社を起業したようでその後は大した人間を雇うこともなく零細システムをほそぼそと作ってきたらしい。学歴も大したことがないんだけど何故か自信満々なんだよ。自分はコードを書けると思い込んでる。「昔はコード書いてたので分かるんですが」とかいちいち言ってくる。でもね、どうも言っていることが時代遅れでガラパゴスなんだよね。なんと英語が全然できないらしい。「英語はアウトプットはできないが読むことはできる」と強がっているけどどうも嘘くさいというか英語情報に全く触れていないことが分かるタイプというか。でもこういうタイプだと低学歴ITの世界では幅を利かせられるらしい。
そんな感じで自信満々で偉そうなガラパゴス男だから話が通じない。自分だけが正しいという態度。急に怒り出すし。DB定義はエクセルで管理して変更履歴もエクセルじゃないとダメだって言うの。それが業界()の常識なんだと。上位互換を既に全部セットアップしてあるのにそれを理解できないのか何なのか。低学歴ITの世界でしか通じない弱小零細SIerの常識を押し付けられても困る。
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
なんかの機能追加というタスクがあるとまずタスクを分割してTODOアプリに登録する
こんな感じ。できる限り1タスク1～5分くらいで終わる量に分割する
1メソッドが大きい場合は例外処理のみ、DB登録部分のみ、メール送信部分のみとかそれだけでもタスクを分ける。
30秒で終わるようなことでもタスクとして独立してたら分けて登録する
「30分あれば上から12個こなせるな」とか見積もりして該当タスクに印をつけて30分タイマーで都度タイムアタックする
タイムアタックが終わると5分ほど休憩。見積もってた分が30分より早く終わってもその時点で休憩。5分くらい？
Youtube見たり在宅だったらえっちぃビデオ見たり音楽聞いたり好きなことをする。
終わったらまた30分分のタスクを見繕ってタイムアタック。それの繰り返し
ちなみにSlackで問い合わせとか来た場合はその時点で返信より前にTODOとして登録。何故ならそうしないと絶対返信忘れるから。
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。
昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。
iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続のハードディスクを、一般的なIPネットワークで規格で仮想化したものです。
マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。
ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。
という事で、仮想環境では実に使いやすいストレージデバイスなのです。
マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。
Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん！ とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。
※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。
[Solved]How to mount iSCSI file?
https://forum.qnap.com/viewtopic.php?f=180&t=25322
[/share/HDA_DATA/.@iscsi.img] # pwd
[/share/HDA_DATA/.@iscsi.img] #
[/share/HDA_DATA/.@iscsi.img] # ls -l
-rw------- 1 admin administ 6442450944 Nov 12 2017 iSCSI-2015ace1-5a078d66.000
-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000
-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000
-rw------- 1 admin administ 5368709120 Nov 11 2017 iSCSI-nss2015-5a06cf6d.000
-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000
-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001
[/share/HDA_DATA/.@iscsi.img] #
※ とても重要
CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする（できちゃいます）と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。
つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。
もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、１台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。
極端な話、ホストのハイパーバイザーは USB メモリやSANブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDDレスなハイパーバイザー運用もできます。
物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。
距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。
【送料無料】QNAP TS－431P2（ホワイト） NAS 4ベイモデル クアッドコア CPU ／ LAN 2ポート搭載 （TS431P2）
価格:56,145円
感想(0件)
iSCSI の耳慣れない言葉に LUN （論理ユニット番号 : Logical Unit Number）というのがあります。
昔の SCSI は、 SCSI バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~７の合計８台（うち大抵７番はSCSI バスカード）の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。
ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。
これが LUN というヤツです。
iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。
別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。
https://en.wikipedia.org/wiki/Logical_unit_number
Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。
Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg
機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。
QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵
Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」＞「システムとセキュリティ」＞「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg
新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。
ＰＲ
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
２分２５秒でした。 大体２０％程度のスループットです。
--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。
Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg
CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。
もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。
ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。
こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。
国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。
こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。
Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。
このあたりは独自OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。
仮想環境でのネットワークアタッチストレージ(NAS)は、本回線（構内LAN）とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが２ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
このご時世、気軽に旅行にも行けない。
そんな中、友人間で流行っているのがdiscordでの思い出語り。
過去に友達と行った数々の旅行やお出かけの写真や動画を見返して懐かしみ、
「また行けるといいな」なんて言いながら、
その日がそう近くないことはみんなわかっているので、ちょっとしんみりして通話を終わる。
ふと思った。
100年後の俺がもし生きていたら、
老衰しきってもはや友達もお互いに五体満足に動けなくなっているかもしれない中で、
せめて過去に縋るときにはこの頃をこそ再び振り返るのではないか？
今まで撮った写真や動画は歴代のスマホ・ガラケーの中にたくさん詰まっている。
容量にすると多く見積もって1TBくらいになるだろう。
例えば向こう10年程度を想定するなら、適当なクラウドストレージにぶち込んでおけば
たまに見返したくなった時の思い出くらいは問題なく満足できるだろう。
ただし今俺が求めているのは、
・今まで撮ってきた思い出のすべてを
である。
たとえば、両親が財布に幼少期の写真をプリントしたものを大事に抱えていることがあるかと思う。
または結婚式のアルバムだったり、写ルンですで撮った褪せた写真の束なども実家なら存在するだろう。
白黒の文字のみを記録するのであれば紙媒体でも100年程度もつかもしれないが、
こと写真において破れたり色褪せたり滲んだり折り目のついたものではもはや満足はできない。
それに1TB分の写真・動画であり、物理媒体に保存した場合はたとえばこれからの引っ越しの際などに
ググったらちょうどいい記事が見つかった。
https://www.itmedia.co.jp/enterprise/articles/1508/26/news007_2.html
紙媒体にも触れていて、結論からすると電子媒体では100年後に残すことは難しいらしい。
続く記事にも、このあと触れようと思っていたクラウドストレージの問題点(データは保証されない、サービスの予期せぬ終了など)があり、
結局はたとえば今ならSSDかHDDあたりにぶち込んでおいて、
適宜マイグレーションを行いながら後世へとつなぐしか方法はないように思える。
ただ、これにも実は懸念があり、
例えば現在主流の圧縮形式、拡張子が100年後も現行で使われているとは限らないためその部分もマイグレーションが必要になり、
そしていつかはマイグレーションすらできないタイミングが発生しうるということだ。
その時俺はどうするのか？
もはや記憶の中の美化された各々の顔や声だけを頼りにするしかないのか？
誰か助けてくれ。
ちなみに26歳です。
すみませーんXPとXで同じバイナリがプログラムフォルダーをコピペでうごきますー出資して マイグレーションということにして。試験費用・・・いくらぐらいい１兆円ぐらい請求していい？
あのテスターの親会社のPさん テストをXPからXへコピペで動きたいんですけどHグレードで。あのるかが入院しまして その先生がつかってもいいよっていうから
よくわからないんですけど先生がいいよっていうグレードで（いちおう親会社にも１報いれる、つけとどけの なまくらであった）
ごめん ランサムふんだって あのるかから警察が電話をうけたばあいにですね 魔王ヨシヒコと 勇者様が たたかって 時空が ねじれていてですね
え？１０兆円にしてくれ？ どうですか？
銀行がかしてくれたおかねで しけんするぉ？
たぶんそれがうちにかせるきんがく ということは うちののうりょくだから どのぐらいのしけんを すればいいか 銀行さんの融資額全力で しけんだぉ？←考え方がおかしい
↓
資格取得の勉強とか、アプリ開発とか、小説執筆とか、何かを成し遂げようと思ったことは幾度となくあるけど、何一つ大きな何かを完遂できた試しがない。
今年もなんたらスペシャリストとかいうIPAの試験受けようと云千円も試験料払ったのに現時点でほぼ無勉状態だからまあ試験日当日にバックれかますつもりだ。
ちなみに半年前は受けなきゃなーとか思いながらも申込みすらサボった。
アプリ開発だって、藤原竜也ツールレベルの細かいのは何回も完成させてるが大きなのはほぼコケてる。
企画はいろいろあったんだよ。決済機能付きの技術投稿サイト。2chAPIを実装した専ブラなしでも使用に堪えうる今風UIの掲示板。対立煽りながら漫画やアニメ作品を格付けさせて2つの作品間の優劣をハッキリさせるサービス。etc。
環境作ったりテーブル設計してマイグレーション走らせてAPI部分だけ作ったけどフロントエンド技術の習得で作業が止まったり、
企画に対して仕様が練りきれなかったり、単純に飽きたり、まあ理由はいろいろあるけどやる気が足りないっていう理由がまあほぼ独占してる。
今は英語の勉強を始めたくてとりあえず単語帳アプリの開発をしてるんだが開発の方に飽きかけてるせいで英語の勉強も始まる前に終わってしまいそうだ。
こんな自分はダメなのはわかってたからまず俺はタスク管理法というのを調べたよ。
Todoアプリはどんなのがあるのかとか、みんなどんな感じでタスク管理してるかとか、タスク管理法のプロマネ向けの書籍を読んだりもした。
そんで俺は平日の終わりに休日にやるべきことを、休日の終わりに平日にやるべきことをタスクとして洗い出してTodoアプリに登録するようにした。
ポモドーロテクニックっていうのを使って(超要約すると25分仕事→5分休憩を4回やって30分休憩、っていうのを繰り返すタスク管理テクニック)
25分の作業を1タスクとして、できるだけ細かく、そして無理のない範囲でタスクを洗い出すことにした。
作業の中には勉強とか開発のものだけじゃなくて例えばSteamの積みゲーを25分間×3回かけて崩すとかアマプラのドラマ何話まで見るとか、そういう遊びのタスクも含めて管理するようにした。
んで今はというと遊ぶ方のタスクだけ前半で綺麗に消化されて2ヶ月くらい前に登録した開発用のタスクをまた来週平日分のタスクとして繰り越そうとしている。
成果としては積みゲー消化がやけにスムーズになってしまっただけ。アレだよ。某Youtuberの『時間足りなかったので1分追加しまーす』ってのを人生の中で延々と繰り返してるんだよ。
ぶっちゃけどんなに緻密にやることをTodo管理しようとしても友人からの『マリカーやろうぜ！』のLINE通知があれば何もかもが崩れてしまう。
いや、そんなもんなくても崩れてるんだろうけど。いやだって勉強よりゲームやアニメって楽しいじゃん。
唯一長年続けられてるものといったら日課的な部屋の掃除とDSの脳トレゲームと筋トレくらい。
生産的なことは何一つやれてねえ。
ぶっちゃけこういうのって脳みそのレベルである程度決まってそうな感じするから単純な精神論行ってても仕方がない気がするんだが、
もうちょっと何か自分を追い込むような方法ってないのかなぁ。なるべくお薬とか以外で。
そろそろ人生的に転職エージェントに相談したり転職用ポートフォリオとか作らなきゃあかん時期なんだけど、このままじゃ転職すらままならねえぞ。
NECの研究提案会議はテーマリーダーがプレゼンを行い、研究所長と中央研究所長が審査するものです。件の研究テーマも、江村氏の責任の下で承認されたもののはずで、それを「まだ～」という発言は極めて無責任だと感じました（私もその場にいました）。また、私がその分野に明るくないことを差し引いても、当時の技術水準であの研究テーマは極めて先端性を有しており、今後20年間のSIビジネスをけん引できる可能性に満ちているものだっと思います。それこそ、「企業の基幹システムのAWSマイグレーションはNECが見積もりも含め、一番仕事が早く、安心感がある」、というようなステータスにすることは可能だったと思います。江村氏はCTOになる以前は、常々から「NECはSIをもうやりません」と公言していましたが、NECのSIビジネスはレベニューの増大は不可能でも、規模としてのシュリンクが非常に困難です。そのため、最低限のSIビジネスをやっている人たちが、それで食っていくための武器が必要です。特に外部リソースの活用が不得手なNECにとって、NEC発の技術なのかどうか、非常に大きな意味をもっています。私がかかわるところでは、顔認識は世界でみれば3流ですが、それでもNEC発であることを最重要視して商流に乗せています。
専門性をもってビジョンを示すことは研究者として重要であることには同意しますが、それは提案を聞く姿勢がある場合に限っていえることです。江村氏の経営では、「わからんから却下、再提案」ということが横行していました。その分野のビジネス判断として事業部とネゴシエーションをテーマリーダは実施してニーズを特定し、ビジネスチャンスを示すこと。そしてリスク要因として将来そのビジネスを取り巻く環境変化を示しても、江村氏はそれらを理解できず、却下することがしばしばありました。無論、配下の研究所長がリーダーシップを発揮し、責任をもって推進する、と援護があれば進むこともありますが、NECではそのようなリーダーシップをはぐくむことは不可能でしょう。なぜならNECのリーダーは、自身の責任を明確化しないまま、YesともNoとも言わずに、上位のポジションが空くのを待つことが基本姿勢だからです。結果、研究者が優れた業績を上げればそのウマに乗ってポイントを得るし、却下した研究テーマで他社が優れたポジションを獲得しても、そのテーマに投資しなくて正解だった、などと宣うのです。
また、CTOブログが言語道断な内容という主張についても、元の増田に同意です。研究資金獲得において、江村氏の発言は全く参考になりえません。資金投入の考え方として、客観指標と主観指標の2つの側面があります。まず、エビデンスや世界情勢への理解といった点で、客観指標としてガートナーレポートに遥かに劣ります。一方、主観指標として役に立つかといえば、意思決定として、NECが注力すべき研究テーマもぼやけており、責任をもって推進する、という姿勢は全く見えません。元の増田氏は江村氏をIT音痴と評していましたが、私はそれに加えてビジネス音痴でもあると思っています。江村氏が重要視し、集中投資したすべてのテーマで競争優位性を確保することができていません（劣化診断や農業ICT、そして漏水検知は試験プレスは出ているのに、正式に導入されたプレスは出ていないことからもわかります）。それを踏まえれば、キャピタリストとしてのCTOに対する評価は、落第も良いところかと思います。それでも江村氏がそのポジションについていることは、単に大チョンボをやらかした研究所出身の國尾氏の後釜という意味合い以上のものはないでしょう。
先日の増田以来、研究所内でも重役に対する評価が変わってきたことは喜ばしい点でもあります。リーダーシップを発揮しようとしない所長に対するレポーティングは省力化を優先するようになりました。彼らはビジネスを動かすことも、資金を調達することも存在感を発揮できないだろう、という見方が強まってきています。この、影響力がない仕事コストを下げようという試みが機能するかどうかは、彼らのプライド次第という面もありますが、うまくいかなければ転職しよう、という現場の考え方が出始めているように感じています。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーごとに作っていてOSもベンダー謹製だよ。性能はいいけどメチャ高いよ。
システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。
オープンソースソフトウェアとは全然関係ないよ。
Q3.使いまわしってどうやってやるの？
A3.80年代とかに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語にコンバートしてリコンパイルするよ。
DBのデータも階層型データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。
あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。
コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。
COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。
Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん
A4.お金が無限にあればできるよ。今の時代にお金があった時代のシステムをフルスクラッチで再開発するととんでもない予算になって市役所内の決裁が通らないよ。
しかも汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから、費用はさらにかさむよ。
Q5.そんなんでよく運用できてたな
A5.当時はSEが汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
