「仮想マシン」を含む日記 RSS

はてなキーワード: 仮想マシンとは

2022-06-11

仮想マシン上のUbuntu 20.04のfirefoxクラッシュするようになった。

新しいプロファイルを作っても解決せん

原因がまったくわからん

これは別ディストリビューション環境を作り直すべきか……

2022-05-28

スゴイいいこと思い付いたんだけど

Windowsパソコンって毎回キッティングが大変なので、

しかしたら全部仮想マシンにしたら管理めっちゃ便利になるのでは?って思った。

せいぜい運用ルーチンとしては

社員の入退社があったら、Active Directoryの追加削除しかなくない?

仮想マシンオンプレミスサーバーに入れてもいいし、

AWSとかAzureとかのクラウドに入れてもいいのでは?って思った。

これ企業パソコンの再発明じゃね?

社員PCの準備はキッティング!って固定概念を打ち砕けよ!

実際あったらネットワークが厳しいかな?でも上手く調節したら

どこからでもアクセスできて便利だと思う。

運用は柔軟になると思うし、ヒットするはず!

2022-05-06

anond:20220506015210

どう考えてもHDDで語ってる化石でしょ

そうじゃなくて支障があると言ってるなら土に埋めよう

 「NEC社内で利用しているVDI環境場合、これまでは仮想マシン1台当たり4GBのメモリ割り当てで十分でした。ところがビジネスチャットWeb会議ツールを頻繁に利用するようになると、4GBではアプリケーションの起動が遅くなったり、Windows全体のパフォーマンスが落ちたりするようになったのです。メモリが足りなくなるとメモリスワップが発生し、SSDを利用していてもパフォーマンスが落ちてしまますユーザーからも『メモリを増やしてほしい』との要望が増え、メモリ割当量を標準で4GBから8GBに拡張しました」

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-09

anond:20220109191529

まずはDockerコンテナ侵入して、

そこからDockerホスト侵入することもできなくはないので、

Docker=セキュアではないと思うけど…

まあ、なんでもそうだけど初期にあった穴はだいぶ塞がれてるはずだけど、

よく不特定多数Dockerコンテナ仮想マシンみたいに使わせるサービスあるけど、

どこまで使わせていいか個人的にはずっと考えてしまうんだよね…

気軽にコードが実行できるサンドボックスみたいに使われてたりするけど…

2021-12-31

貴社のテレワークに最適なVDI 代替の選定ガイド

VDI(仮想デスクトップ代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連

載「テレワーク時代Web 分離入門」。 第1 回、第2 回でテレワークWeb 分離の方式の特徴を解説しました。

最終回となる今回は、方式レベルでの選定方法を紹介します。

今回のゴール

用途観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ

りません。

(出典:ネットワンシステムズ

今回は、読者の皆さんが自組織マッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい

のか」という疑問に回答します。

フローチャートで分かる、

貴社のテレワークに最適なVDI 代替の選定ガイド

VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最

終回は、VDI 代替ソリューション方式選定における 4 つのポイント解説して、各方式を比

します。

(2021 年03 月04 日)

26 →目次に戻る

4 つのポイント

これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイント論点が集約されます

1. ブラウザだけで業務が完結するかどうか

2. データを処理するマシンローカルマシン大丈夫かどうか

3. データを処理するマシン物理PC大丈夫かどうか

4. 実行環境が分離されている必要があるかどうか

これらを基に、方式選定に使えるフローチャートを作ってみました。

(出典:ネットワンシステムズ

ポイント 1】ブラウザだけで業務が完結するかどうか

ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリ安全に利用させたいのか」

という業務特性に関わる要件です。

テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け

できますWeb 分離用途では、前者が仮想ブラウザ方式後者がそれ以外の方式となります

27 →目次に戻る

ポイント 2】データを処理するマシンローカルマシン大丈夫かどうか

次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。

プログラムの実行環境が手元のPC となる場合データも手元のPC に保存されます。つまり、手元のPC

まれ場合、保存されているデータも盗まれしまます

ディスク暗号化している、生体認証有効にしている、だから大丈夫」と言い切れるならいいかもしれません

が、「技術進歩によって将来的に突破されるかもしれない」といった懸念払拭(ふっしょく)できない場合、仮

デスクトップ方式リモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必

要があります

その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式VPN

方式)やアプリラッピング方式マッチするでしょう。

なお一般的に、リモートデスクトップ方式VPN 方式テレワーク用途のみで導入されますが、仮想 デスクトッ

方式アプリラッピング方式は、テレワークWeb 分離、どちらの用途にも利用できます

ポイント 3】データを処理するマシン物理PC大丈夫かどうか

ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続

性を考えるとよいでしょう。

リモートデスクトップ方式場合、社内の自席にPC物理的に存在することが前提です。そのため、自席 PC

故障したときに「何もできない」状況になります

一方、仮想デスクトップ方式場合マシン仮想化されており、多くの環境において仮想マシン動作してい

サーバ群はn +1 などの方式冗長化されています。そのため、非常に強い障害耐性があります

障害耐性を高めたい場合は、仮想デスクトップ方式ベストです。業務が停止するなどのリスク運用でカバー

できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。

28 →目次に戻る

ポイント 4】実行環境が分離されている必要があるかどうか

ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報

えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれしまった場合を想定しましたが、ここ

ではプログラムの実行そのものに対するリスク検討します。

手元のPCプログラムを実行するということは、つまり「端末の脆弱(ぜいじゃく)性を突いたゼロデイ攻撃

を受けるリスク存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合情報を抜き取られてしま

ます

従って、例えば VPN 方式を導入する場合、「EDR(Endpoint Detection and Response)で脆弱攻撃

策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラム制限する」「屋

外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要

あります

このような徹底した対策継続して運用できる組織に限っては VPN 方式有効選択肢ですが、筆者としては

安易VPN 方式の導入を推奨することはできません。

VPN 方式安価かつ容易に導入できるので、昨今のテレワーク需要高まる状況では、多くの組織上記のよ

うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしま

場合は、これを機に腰を据えて見直してみてはいかがでしょうか。

• 参考リンク日本経済新聞「在宅時代落とし穴 国内38 社がVPN不正接続被害

また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ

フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い

ます

• 参考リンク:Verizon Communications「Verizon Network Report」

29 →目次に戻る

それぞれの方式比較

ここまで、要件ベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか

らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。

この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策

を考える」といった検討を具体的に進めることができると思います

以降の表の見方説明しておきます。緑塗りのセルポジティブな内容、赤塗りのセルネガティブな内容、黄

塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項

記載しています

なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト運用体制、セ

キュリティ業務継続性など、いろいろな観点からトレードオフ方式を選定することになります

できる作業

(出典:ネットワンシステムズ

仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバ操作といった、ブラウザ以外のアプリ

は使えません。多くの場合Windows統合認証など Windows依存する機能も利用でません。

また、印刷に関しても確認必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の

ステップとなる製品選定の段階で確認した方がよいでしょう。

30 →目次に戻る

コスト

(出典:ネットワンシステムズ

会社PC 持ち帰り方式VPN 方式)とリモートデスクトップ方式は、端末のアップデート故障時の交換など、

端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に

あります

その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象マスター OS のみであり、仮

マシンを一気に展開できるので、運用員の集約化が可能です。

VDI の運用ナレッジ豊富SIer に依頼することで、作業内容の質を落とさずにコスト圧縮できる効果が期

待されます

運用

(出典:ネットワンシステムズ

仮想ブラウザ方式アプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう

か」などの動作確認を、あらかじめ実環境実施しておく必要があります。この動作確認は、運用フェーズにおい

ても継続する必要があります

また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲

覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります

31 →目次に戻る

セキュリティ

(出典:ネットワンシステムズ

マルウェア対策については、会社 PC 持ち帰り方式VPN 方式)やリモートデスクトップ方式仮想デスクトッ

方式は、EDRアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式アプリラッピン

方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式ファイルの実行を禁

止する」などの機能を標準で実装しています

重要情報の盗聴については、リモートデスクトップ方式仮想デスクトップ方式仮想ブラウザ方式(画面転送

型)は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強

みがあります

最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。

ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須

といえます

おわりに

これで 3 回にわたる連載は終了です。いかがだったでしょうか。

セキュリティ利便性トレードオフ関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ

方式」がバランスの良い方式だと思います

仮想デスクトップ方式仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな

い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう

に利用できる」という汎用(はんよう)性の高さがあり、これが他の方式より優位な点となっています。一方、仮

ブラウザ方式は、用途限定されるものの、ユーザーにとっては利便性が高く、初期コスト観点では仮想デス

トップよりも導入しやすいので、Web 分離の第一候補になってくると考えます

2021-12-30

仮想化時代NAS 選び - やっぱり iSCSI は早い。


仮想システムを構築するにあたり、CIFS しか使えない NASバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。



テストに使う NAS は QNAP の Turbo NAS TS110

http://www.tekwind.co.jp/products/entry_6719.php

です。もう6年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。

昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます

iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続ハードディスクを、一般的IPネットワークで規格で仮想化したものです。

マウントするホストシステム側は iSCSI initiator, ディスクストレージ機能提供する側を iSCSI Target と呼びます

ホストからマウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスク故障などで、一時的物理的に取り外さなければいけない場合でも、ホストから操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます

という事で、仮想環境では実に使いやすストレージデバイスなのです。

マウントするホストから見ると単純に SCSI/SASハードディスクに過ぎません。iSCSIストレージマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットフォーマットする必要があります

LinuxiSCSI ターゲットからは、内部にターゲットとして使う「巨大なファイル」が、どん! とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプル仮想イメージなので、ファイルのものバックアップコピーすれば、ストレージイメージのものバックアップができます

※ 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] #

[/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 デバイス複数作れるので、1台の iSCSI 装置複数ターゲット実装して、複数ホストから別々のターゲットイメージマウントする事は問題ありません。

極端な話、ホストハイパーバイザーは USB メモリSANブートさせて、後はマウントした iSCSI仮想イメージ上で、仮想マシンを動かす、HDDレスハイパーバイザー運用もできます

物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb baseネットワークカードHUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまます

距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットデータセンターに置く、なんてこともできます

【送料無料】QNAP TS-431P2(ホワイトNAS 4ベイモデル クアッドコア CPULAN 2ポート搭載 (TS431P2)

価格:56,145円

(2019/7/27 12:05時点)

感想(0件)

  • LUN -

iSCSI の耳慣れない言葉に LUN (論理ユニット番号 : Logical Unit Number)というのがあります

昔の SCSI は、 SCSI バスアダプタに7番のIDを振り、残りの 0 ~ 6 のディスクCD, Tape などに ID を振り分ける物理的な3ビットディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。

まり初期のSCSI 規格では8つ分。

これが実に難物でした。特に複数SCSI バスアダプタカードをデュプレクス設定する場合割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。

まりつのSCSIバスには 0~7の合計8台(うち大抵7番はSCSI バスカード)の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。

ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスク複数論理番号に分割したわけですね。

これが LUN というヤツです。

iSCSI 機器ターゲットも、内部のソフトウェア的に複数論理デバイスに分割して、複数ホストコンピュータから複数物理デバイスのように見せかけるわけです。

別々な LUN は一つ、あるいは複数iSCSI 機器によって、複数ホストに別々のディスクデバイスとして見せかけるンです。

まぁ、いい加減な説明なので、他所で調べてください。

https://en.wikipedia.org/wiki/Logical_unit_number

Qnap NAS場合iSCSI ターゲットウィザード形式簡単作成できますEXT4 ファイルシステム上で、オンラインでも簡単サイズの拡大ができるので、 Windows の Storage Server のように NTFSVHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。

Qnap NASiSCSI ターゲットの設定は、偉そうな Linuxサイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg

機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーNASとの接続プロトコルの性能差が、如実に現れる事になります

QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵

10GbE接続対応 NAS

Windows10 の MicrosoftiSCSI イニシエータは「コントロールパネル」>「システムセキュリティ」>「管理ツール」の中にあるので、ここで、設定済の iSCSIターゲットを」 「検索」して選んで「接続します。Chap 認証を付けておいた場合ターゲットで設定したパスワード必要でしょう。

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg

新規作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲット仮想ディスクは、他のマシンマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。

PR

ちなみに opeSUSE で使うにはこんな感じになりました。

open SUSE Leap 15.1 で iSCSI NASを使ってハマった

https://islandcnt.exblog.jp/239328437/

  • CIFS の性能を見てみる -

一番イラつくのは、巨大なファイル転送でしょう。という事で 3G 程ある SUSE LinuxインストールDVDISO ファイルを CIFS でコピーしてみます

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg

3分11秒かかりました。1Gビットネットワーク12~3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。

スループットは 150Mbps 程度で全体の最大15%程度でしょうか。

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg

次に iSCSI マウントしたディスクコピーしてみます

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg

初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg

2分25秒でした。 大体20%程度のスループットです。





--

数字に弱い私の脳みそですが、 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 を搭載して、低価格NASUnix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います

Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。

このあたりは独自OSNAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジNAS として利用したほうが良いと思います

仮想環境でのネットワークタッチストレージ(NAS)は、本回線(構内LAN)とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーNAS間で凄まじい通信が発生します。サーバーNICが2ポート以上のものが推奨されます

  •  誤解していけないのは --

iSCSIあくまでもネットワーク上のストレージのみの機能提供するものであり、ファイル共有の手段ではない、という事です。

NAS をCIFSで使うと NAS が持つ独自アクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自機能で設定します。

iSCSIあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSのものファイルシステムセキュリティ機能アクセス制限ホスト側の機能をそのまま利用できますセキュリティ的には、マウントする際のパスワード制限しかないので、独自ストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。

2021-09-19

去年DNSの設定かなんかではてなブックマークだけページ表示に3秒待たされた

あの挙動はなんだったのだろうか

仮想マシンということもからんでいそうだが結局原因はわからんかった

2021-09-17

転職するときに重視するもの

PCスペック

・社内システムの新しさ

である

これを無視している人が意外と多い。

6年前に正社員支給されたPCが当時としてはめずらしいSSDで、速さに感動した。

そのあと派遣に戻ったらクソスペPC支給されて、全てに1テンポ待たされる動作だった。

その後また転職したところでは仮想マシンだったのでサクサクだった。

経営者PCスペック従業員スペックも変わるのだということを知ったほうがいい。

次の職場ではゴミPC与えられたら拒否しようと思う。

2021-07-12

EMPRESSによると、「バイオハザード ヴィレッジ」にはDenuvoに加え、開発・販売であるカプコン独自DRM技術Capcom Anti-Tamper」が搭載されており、これこそがカクツキの原因であったそうです。EMPRESSは「ゾンビを倒す際に発生するようなカクツキは全て修正された」と述べています。また、EMPRESSは「カプコンDRM技術がDenuvoの仮想マシンを難読化し、動作さらに遅くさせていた」と述べ、怒りをあらわにしています

こう言うと美談に聞こえるけど、なんでこの手のハッカー共って自分がやったことより他人責任比重を重くとって正義を振りかざすんだろう

コミュニティ煽りたいんだろうけどさ

それでお前らのやったことが消えるわけではないしな

そもそもこういう手合を避けるためにガードを盛り込んでるのに、それを外して怒ってるとかどれだけ自分勝手なんだと思うしね。

2021-02-09

anond:20210208152609

とりあえず仮想マシンアーカイブして、全部ローカル仮想環境で動くようにしておくのがいいかと。

それでも古いVMが動かないとかあるのが厄介だが。

なんだよ仮想環境ホストOSアップデートで動かなくなるって。

仮想マシン意味ないやん。

2020-12-24

anond:20201222230319

今のM1が出る前の春頃のMacBookAir。盛って20万くらいだったかな。

M1が出て当初は悔しい気がしたが、仕事用なので秋まで待つわけに行かんのと、仮想マシン系処理が軒並み全滅っぽいから安定するまで使えなさそうで諦めがついたw

その次が冷蔵庫。設置配送込で17万くらいか冷蔵300/冷凍200リットルくらいあるでかいやつ。

前のでも全然使えたが子供離乳食やら何やらで必要だとか。

2020-10-27

仮想マシンWindowsを飼うか、やっすいPCを1台買っちまうか

2020-08-09

家に使ってないパソコンHDDがたくさんあったので

1台のPCで4つのサービスを稼働していたところを

4台のPCに一つずつ稼働させることにした。

【よかったこと】

IISというWindowsサーバー建てるフレームワークみたいのを使って初めてWindowsサーバーを建てる経験を得られた。

  Windowsサーバーを立てるのは規約違反だった気がしたが最近Windowsに元々サーバーを建てる機能付属してるし別にいいのだろう。

Windows10ドライバ認識能力のすごさを知ることができた。

  Linuxだとファンが回らない、何も映らないけどWindowsだと普通に動くなどした。

Windowsサーバーを建てるのはムズイという知見を得た。

  ・信じられないくらい遅い

    CPU使用率が低いままで全く変わらず、にもかかわらず簡単ウェブページの表示に10秒とか待たされて使い物にならなかった。Xubuntuに変えたら1秒以内に表示された。

  ・操作Linux全然違う。

    httpsリダイレクトされるのをやめさせようとしたり、SSL証明書を設定しようとしたがどうやってもできなくてWindowsを使うこと自体を辞めた。

・一つのPCで一つのサービスが動いているので気分がいい。

・家に余ってたHDDを全部繋げて1.5TBのクラウドサーバーを作ることができた。

  複数HDDを一つのHDDとして扱う技術(LVM)の設定をする体験ができた。1.5TBの使い道はない。不用品処分をするのが目的

XubuntuならMacbookPro(2007年製)にUSBメモリからインストールできることを知った。ただしインストール画面がたまにしか表示されない。

デメリット

・今までは仮想マシンで動かしていたので扱いやすかったのだがそれができなくなった。

  失敗しても5分前の状態に戻すとかできないし、仮想イメージエクスポートとかできない。

電気代を4倍食うようになった。

・ownCloudをアップデートしたらGalleryというプラグインが動かなくなった。

2020-06-03

最近Windowsが気に食わない

なんかLinux寄りになっててなんだそりゃ?みたいな感じ

そら、cygwinとか仮想マシン使うよりは楽かもしんないが、なんかそこまでは・・・って気になる。

dockerネイティブに使えて、pythonrubyも変なパッケージインストールしなくてOKってのは嬉しいが、なんか面白くないんだよなぁ。

EdgeBlinkベースになるし、何いい感じに収まってんだよみたいな。

GitHub買って、npm買って悪かねぇんだけど、なんだかなぁ

つーか、早くslideshareログインMicrosoftアカウントOKしろよ。

2020-04-14

技術的なこと、なのか?

自分の勤め先は、自席のPCから直接Webを見ることができなくて、外へつながってるサーバリモートデスクトップ接続して仮想マシンWebを見に行くようになっている(こういう説明で合ってるのか?)。

仮想マシンWindows 10なので当然ライセンス必要わけだが、うちは金がないのでライセンス数が少ないらしい。

(「らしい」というのは、ちゃんとした数を聞いたことはないものの、仕組みを導入した当初は各部から1台だけしか接続できなかったから、たぶん少ないのだろうなと)

なので仮想マシン接続しっぱなしな人が多いと悪影響があるわけだが、そういうことを知らないオジサンたちはWebを見るにしろ見ないにしろとりあえず今日仮想マシン接続したままだ。

情報システム部門も、もーちょっと説明すりゃいいのに…

2020-01-13

PX-W3PE4を使った録画環境メモ

今までPT2を使った録画サーバーを構築運用していたが性能に限界を感じマザーボード等を交換。

最近のは当然PCIなんてないマザーボードが大半で、いい機会だからと思いPX-W3PE4に移行しようと思ったのが苦難のきっかけ。

Windows環境だと不安定

これを素直にWindows環境で使おうとするとドロップが多く不安定

Linux非公式ドライバを使えば安定しているという話を見つけ実際使ってみると安定して動作することを確認

でも今までの自作アプリ等の資産を生かしたいということでWindowsで録画したい。

そのため別のPCUbuntuを入れBonDriver_Mirakurun経由でWindows飛ばし動作させることに。

サーバーを減らしたい

ただこの構成だとサーバーが二台になってしま邪魔電気代が心配という状態に。

Raspberry Piでも使おうかと思ったが、USBを使える仮想マシンを使えばそれも不要じゃね?と思いとりあえず試すことに。

Hyper-Vを別用途使用しており、最初DDAを使えばいけるかと思ったがWindows10のクライアントHyper-Vでは使用できない。

https://docs.microsoft.com/ja-jp/windows-server/virtualization/hyper-v/deploy/deploying-graphics-devices-using-dda

https://www.atmarkit.co.jp/ait/articles/1810/09/news009_2.html

ならばと思い、最近Hyper-V共存できるとされていたVirtualBoxを使うことに。

がこれもWindwos10 1903で壊れたらしく使えず。

https://forums.virtualbox.org/viewtopic.php?f=6&t=90853&start=180

なのでUSBデバイスWindowsサーバーLinuxクライアントに使えるVirtualHereで行くことに。

https://www.virtualhere.com/home

(制限付きで無料デバイス1台までは使える)

帯域はそこそこ食うが(1チャンネル16Mbos程度)影響がないようにHyper-V機能で切り分けて使用

値段考えるとRaspberry Piサーバーにした方が良い気がするがどれぐらい性能が必要自分には分からないのでこの構成で行くことに。

2019-07-30

anond:20190730193103

VirtualBoxかなんかで仮想マシン立ち上げて古いバージョンOS上で古いブラウザ立ち上げてその中でflvでも何でも開けばいいだろ。

そのぐらいの知識は持っとけよ常識だろ…

ログイン ユーザー登録
ようこそ ゲスト さん