自作サーバでも作ろうかと考えてる

格安自作サーバでも作ろうかと考えている。

予算としては3万円くらい。

といっても場所をそこまで大きく取りたくないし・・・といろいろと見てたらベアボーンというのが良さそうだった。

 

そもそもコンピュータは何がいるのか

家のPCは一応自作ではあるけど、コンピュータの先生と一緒に秋葉原で買い物をして漏れなく完璧なPCができあがったのであった。

ようは自分で判断が付かないんですよね。

自分の認識では、

 

 

ベアボーンは箱と電源とマザーボードが一緒になっているもの。

価格コムで売れ筋ナンバーワンは以下の商品。これ安くていいね!

 

 

MiniDesk110。

となると、あとはCPUとメモリとストレージを買えばいいわけで、とはいってもパーツを買ったらささらなかった、認識しなかったということがないように慎重に選ぶ本当の戦いが始まるわけです。

 

マザーボードを基準に考えてみる

基本的にパーツはマザーボードにささるわけなので、ベアボーンに搭載されているマザーボードがどういった規格で接続できるかどうかをちゃんと知る必要がある。

Deskmini110に搭載されているマザーボードについて調べてみた

 

マザーボードの規格

まず規格として、Serial-STXというサイズのマザーボードらしい。

マザーボードのサイズによって、拡張性が変わってくる。接続できるインタフェースの数も差が出てくるし、搭載できるパーツの種類がサイズによって変わってくるため。

Mini-STXより小さいものでNUCというものがあるらしい。

ただ、NUCに関しては箱、電源、マザーボードに加えてCPUも一緒についてくるらしい。

超小さい。

 

搭載可能なメモリ

 メモリについて考える点は以下の2点。

モリーサイズ

メモリ自体の物理的なサイズで種類がある。

  •  大きなサイズのDIMM
  • ちょっと小さなS.O.DIMM
  • かなり小さなMicroDIMM

 の3種類がメイン。MiniDesk110はS.O.DIMMサイズがささるマザーボードとなっている。

メモリ・モジュール規格

S.O.DIMMに着目して見てみる。

DeskMini110はDDR4-2133という規格に対応している。

前のDDRxxは、メモリ規格を表す。これはマザーボードに合った規格を厳密に選ぶ必要がある。

後ろの数字はモジュール規格のクロック数を表し、数字が大きいほど処理速度が速い。

モジュール規格は上位互換はなく、下位互換は対応している

例えば、S.O.DIMMのDDR4-2400(上位互換)をDeskmini110にさすと挿したメモリ自体は2400MHzのパワーを持っているがマザーボードに合わせて2133MHzで動作することになる。逆は不可能。

 

なので、Deskmini110で動作するメモリを購入する際には、S.O.DIMMサイズでDDR4の名が付いた2133MHz以上のクロック数のメモリを買う必要がある。

 

搭載可能なCPU

CPUを選ぶ際には一つだけ気にすればいいっぽい。

ソケット形状

Deskmini110ではLGA1151というソケット形状に対応するらしい。

少し古い世代でLGA1150やLGA1155があるが、古いCPUのみに対応しており最近のCPUは乗らない。また、互換性は全くない。おそらく物理的に形状が違うためだと思う。

おもしろいのはソケットの形状によって搭載可能なメモリー規格が変わってくること。先出のDDR4が乗るソケット形状はLGA1151だけみたい。

 

搭載可能なストレージ

搭載可能なストレージについては癖がありそう。

 調べていて相当分かりにくかった。

おそらく、以下に出てくる接続形状とインタフェース(転送方式)で類似した名前が使われてるせいだと思う。

接続形状

マザーボードとどういう形状で接続ができるかどうか。

 これら全て接続の形状の話。

この中では、SATAに関してはケーブルを購入して、マザーボードSSDを接続する形態をとり、その他はSSDと接続コネクタが一体となっている。※昔のゲームカセットみたい。

 

インタフェース(転送方式)

どういう方言でデータの受け渡しを行うか。これもややこしく、物理インタフェースで代表的なものは以下。

 

さらに論理インタフェース(制御機構の部分)にも種類があるようで

  • AHCI
  • NVM Express(NVMe)

 

厳密にはNVMeというコネクタもあるっぽい。接続形状とインタフェースがセットになって登場しているのかなんなのか分からないけどただただ、分かりにくい。

 

Deskmini110は、

m.2.SSDPCI ExpressのインタフェースでNVMeのやつを買わないといけないようです。

って高いわ!

最新規格詰め合わせで高すぎる。ストレージだけで3万円いきかねない。

調べてみたらSATAのやっすい2.5インチSSD/HDDが2基搭載できるらしい。

これ使うってことでいいや。

 

 買うもの

上記をふまえて買うものを決めた。

 

  • 箱・・・DeskMini 110
  • CPU・・・Pentium G4560
  • ストレージ・・・Ultimate SU800 ASU800SS-256GT-C
  • メモリ・・・D4N2133PS-8G

 

 

4万円くらいか・・・。3万円では無理だった。

ひとまずぽちるか!

Azureについての備忘録

Azureについて調べたメモ。

テンプレートをいじる

AWSでCloudFormationをいじっているので、Azureでの類似機能であるResource Managerを軽く触れてみた。

結論として、AWSほど多くのことをテンプレートでカバーできるかが怪しいという印象、コードでインフラをするのであればJSONではなくPowerShellをカタカタした方がいいと感じた。

VirtualMachine主体の構造

AWSでは、VPCをまず配置し、サブネット及びAZを決定したうえでEC2を配置する考え方だけど、

Azureではまずは仮想マシン(VirtualMachine)を配置し、その仮想マシンが所属するネットワークやサブネットの情報はあくまで一要素に過ぎないような考え方になってる。

リソースコンポーネントが細かい

AWSのEC2では、ストレージやネットワーク情報はEC2リソース情報に過ぎないけど、Azureではストレージ及びNICそれぞれが仮想マシンと並んで一つのリソースとして扱われる。

作成順序に気を使う必要あり

AWSではテンプレートからのデプロイ時の各コンポーネントの作成は自動的に矛盾がない順序で行われたが、Azureでは作成者が気を使う必要あり。

※dependsOn関数とReference関数

例えば、仮想マシンAにストレージBを付ける、と定義する際にストレージBが存在しないのに仮想マシンAを作成しようとしても仮想マシンAからすればBが何のことだか分からない。そのため、dependsOn関数もしくはReference関数であらかじめBを宣言しておく必要がある。

 

vNET間を接続する

vNET (VPC)間を接続する際に参考になりそうなものをメモ

www.rem-system.com

 

docs.microsoft.com

Route53が気になったので調べた。

AWSのRoute 53の機能が気になったので調べてみた。

 

気になった機能

ALIASレコード

CNAMEレコードと似ている。

CNAMEレコードとは、あるホストの名前解決を別の名前へ挿げ替えることが可能。例えば「www.abc.com」のDNSクエリがあった場合に「www.def.com」へ転送することができる。

ただし、CNAMEレコードでできないこととして、Zone Apex (あるドメインの頂点、例えばabc.comなど)を転送元として設定ができない。

ALIASコードはそれが可能であることが特徴。

AWSの各サービスのエンドポイントの名前解決に利用できる。

 

加重ルーティング

レコードセット(名前とIPアドレスの組み合わせ)に重みを付けて、ルーティング先の頻度を決定できる。

 

レイテンシールーティング

クライアント端末からAWSリージョンへのレイテンシが最小のエンドポイントを選択して、ルーティングさせる。

 

フェールオーバールーティング

ヘルスチェックと組み合わせ、名前解決によりアクティブ/パッシブフェールオーバーを実現できる。

TCPレベル、HTTP/HTTPSレベルのモニタリングが可能。

 

(例)こんなことが可能

f:id:no1497:20170416000237j:plain

 

AWS Black Belt Tech シリーズ 2016 - Amazon Route 53より

 

上記のような複雑な設定を行うのに、トラフィックフローのインタフェースを使ってGUIベースで設定が可能。

 

トラフィックフローはこんなの↓

f:id:no1497:20170416000814p:plain

Amazon Web Services ブログ: 【AWS発表】Amazon Route53 トラフィックフローより

 

いじってみよ。

CloudFormationをいじる ELB基礎編

今日はELBをいじった。

CloudFormation楽しい。

 

参考記事はこちら。

docs.aws.amazon.com

 

テンプレ例

f:id:no1497:20170411235015j:plain

 

今回はこれを作ります。ELB意外は前回と同じ要領。

例によって最低限の構成テンプレ。

ELBテンプレ

HTTP(TCP/80)で待ち受け、登録インスタンスへHTTP(TCP/80)で配布するELB:"ELB1"を作成

ELB1はセキュリティグループ:"SecurityGroup2"に属し、サブネット:"Subnet2"へ属する。

登録されているインスタンスインスタンス:"Instance1"と"Instance2"

※この二つのインスタンスがHTTPでELBから振り分けた通信を受け取る。

        "ELB1": {
            "Type": "AWS::ElasticLoadBalancing::LoadBalancer",
            "Properties": {
                "SecurityGroups": [
                    {
                        "Ref": "SecurityGroup2"
                    }
                ],
                "Instances": [
                    {
                        "Ref": "Instance1"
                    },
                    {
                        "Ref": "Instance2"
                    }
                ],
                "Listeners": [
                    {
                        "LoadBalancerPort": "80",
                        "InstancePort": "80",
                        "Protocol": "HTTP"
                    }
                ],
                "Subnets": [
                    {
                        "Ref": "Subnet2"
                    }
                ]
            },

 

ソース

www.dropbox.com

CloudFormationをいじる RDS編

RDSでのDB + WebAPの構成を作成する。

 

RDSを作成する際はパラメータが多いけど、

例のごとく最低限のパラメータで作成する。

 

以下のサイトが分かりやすい。

qiita.com

 

recipe.kc-cloud.jp

 

DBセキュリティグループとVPCセキュリティグループの違い。

今はDBセキュリティグループは使わないんだね。

docs.aws.amazon.com

 

 

テンプレ例 

最低限のパラメータで作るテンプレ例。 

DBサブネットグループテンプレ

サブネット:"Subnet2"とサブネット:"Subnet3"を持つDBサブネットグループ:"RDSSubnetGroup1"を作成

※RDSインスタンスが所属するDBサブネットグループは少なくとも2つのサブネットを持つ必要があるので、DBサブネットグループというものが存在する。2つのサブネットはAZが異なる必要があり、マルチAZのため?

        "RDSSubnetGroup1": {
            "Type": "AWS::RDS::DBSubnetGroup",
            "Properties": {
                "DBSubnetGroupDescription": "Subnet2 for RDS",
                "SubnetIds": [
                    {
                        "Ref": "Subnet2"
                    },
                    {
                        "Ref": "Subnet3"
                    }
                ]
            },
        },

 

サブネットテンプレ

VPC:"VPC1"に所属し、AZ:"us-east-1a"を持つ192.168.2.0/24のサブネット:"Subnet2"を作成

VPC:"VPC1"に所属し、AZ:"us-east-1b"を持つ192.168.3.0/24のサブネット:"Subnet3"を作成

異なるAZを二つ作成するためにAZを明示

 

        "Subnet2": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "AvailabilityZone": "us-east-1a",
                "VpcId": {
                    "Ref": "VPC1"
                },
                "CidrBlock": "192.168.2.0/24"
            },
        },

 

        "Subnet3": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "AvailabilityZone": "us-east-1b",
                "VpcId": {
                    "Ref": "VPC1"
                },
                "CidrBlock": "192.168.3.0/24"
            },
        },

 

セキュリティグループテンプレ

VPC:"VPC1"に紐づくセキュリティグループ:"SecurityGroup2"を作成。

送信元192.168.1.0/24からのインバウンド方向TCP/22~22 通信を許可。

 

        "SecurityGroup2": {
            "Type": "AWS::EC2::SecurityGroup",
            "Properties": {
                "VpcId": {
                    "Ref": "VPC1"
                },
                "GroupDescription": "Allow access only EC2",
                "SecurityGroupIngress": [
                    {
                        "CidrIp": "192.168.1.0/24",
                        "IpProtocol": "TCP",
                        "FromPort": "22",
                        "ToPort": "22"
                    }
                ]
            },
        },

 

RDSインスタンステンプレ

本体。

ストレージサイズ5GB、インスタンスタイプdb.m1.small、データベース種類MySQLのRDSインスタンスを作成

セキュリティグループ:"SecurityGroup2"、DBサブネットグループ:"RDSSubnetGroup1"、に所属させる。

ユーザー:"MyName"、パスワード:"MyPassword"で作成。

 

        "RDSInstance1": {
            "Type": "AWS::RDS::DBInstance",
            "Properties": {
                "AllocatedStorage": "5",
                "DBInstanceClass": "db.m1.small",
                "Engine": "MySQL",
                "MasterUsername": "MyName",
                "MasterUserPassword": "MyPassword",
                "DBSubnetGroupName": {
                    "Ref": "RDSSubnetGroup1"
                },
                "VPCSecurityGroups": [
                    {
                        "Ref": "SecurityGroup2"
                    }
                ]
            },
        },

 

上記テンプレを合体

VPC前回の記事を流用。RDS部分のみのコンポーネントは以下になる。

f:id:no1497:20170409215805p:plain

 

 

前回の記事と今回の記事を合体させたtemplateファイル。

 

www.dropbox.com

CloudFormationをいじる VPC EC2基礎編

CloudFormationをいじります。

最低限の操作を抑えたい。

 

となると、以下のサイトがとてもわかり易い。

dev.classmethod.jp

 

dev.classmethod.jp

 

 

テンプレ例

入門者向け、コピペで役立つ最低限のテンプレ。

VPCテンプレ

 

192.168.0.0/16のセグメントを持つVPC:"VPC1"を作成

        "VPC1": {
            "Type": "AWS::EC2::VPC",
            "Properties": {
                "CidrBlock": "192.168.0.0/16"
            },
        },

 

サブネットテンプレ 

VPC:"VPC1"に紐づく192.168.1.0/24のセグメントを持つサブネット:"Subnet1"を作成

        "Subnet1": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "VpcId": {
                    "Ref": "VPC1"
                },
                "CidrBlock": "192.168.1.0/24"
            },
        },

 

ルートテーブルテンプレ

VPC:"VPC1"と紐づくルートテーブル:"RouteTable1"を作成

※サブネットとの紐付けはプロパティに書かないんだ・・・。

以下、ルートテーブルサブネット結合必須

        "RouteTable1": {
            "Type": "AWS::EC2::RouteTable",
            "Properties": {
                "VpcId": {"Ref":"VPC1"}
            },
        },

ルートテーブルサブネット結合テンプレ

ルートテーブル:"RouteTable1"とサブネット:"Subnet1"を紐付けるルートテーブルサブネット結合:"RouteTable12Subnet1"を作成する。

        "RouteTable12Subnet1": {
            "Type": "AWS::EC2::SubnetRouteTableAssociation",
            "Properties": {
                "RouteTableId": {
                    "Ref": "RouteTable1"
                },
                "SubnetId": {
                    "Ref": "Subnet1"
                }
            },
        },

 

ルートテンプレ

ルートテーブル:"RouteTable1"に紐づく、宛先0.0.0.0/0のネクストホップを"IGW1"とするルート:"Route1"を作成

※ちなみにここでのIGW1はインターネットゲートウェイコンポーネント

        "Route1": {
            "Type": "AWS::EC2::Route",
            "Properties": {
                "DestinationCidrBlock": "0.0.0.0/0",
                "GatewayId": {
                    "Ref": "IGW1"
                },
                "RouteTableId": {
                    "Ref": "RouteTable1"
                }
            },
        },

セキュリティグループテンプレ

VPC:"VPC1"に紐づくセキュリティグループ:"SecurityGroup1"を作成。

インバウンド方向TCP/22~22 any通信を許可。

 

        "SecurityGroup1": {
            "Type": "AWS::EC2::SecurityGroup",
            "Properties": {
                "GroupDescription": "Allow SSH",
                "SecurityGroupIngress": [
                    {
                        "IpProtocol": "TCP",
                        "FromPort": "22",
                        "ToPort": "22",
                        "CidrIp": "0.0.0.0/0"
                    }
                ],
                "VpcId": {
                    "Ref": "VPC1"
                }
            },
        },

EC2作成テンプレ

セキュリティグループ:"SecurityGroup1"、サブネット:"Subnet1"に属するt2.microのAmazon Linux AMIインスタンス(バージニア北部 "ami-22ce4934")を作成

        "Instance1": {
            "Type": "AWS::EC2::Instance",
            "Properties": {
                "InstanceType": "t2.micro",
                "ImageId": "ami-22ce4934",
                "SecurityGroupIds": [
                    {
                        "Ref": "SecurityGroup1"
                    }
                ],
                "SubnetId": {
                    "Ref": "Subnet1"
                }
            },
        },

上記テンプレを合体

以下のようになります。

 

f:id:no1497:20170408212155j:plain

 

www.dropbox.com


AWS個人的に気になったワードまとめ(編集中)

  • Mシリーズインスタンス
    汎用利用のインスタンス種類。Tシリーズとは課金が異なる。
  • RI
    リザーブインスタンス。時間単価契約ではなく年間契約となる代わりに安く利用できる。
    【昔】
    軽度利用、中度利用、重度利用からの選択。
    【今】
    前払い、一部前払い、前払いなしから選択。
  • Cシリーズインスタンス
    コンピュート最適化のインスタンス
  • Route53のラウンドロビン
    DNSラウンドロビンが可能。Weightedなどポリシーオプションも豊富。
  • レイテンシーベースルーティング(Route53)
    アクセス元のレイテンシーを判断し、最も近いリージョンのアドレスを返すDNS機能。CDNは静的コンテンツだが、これであれば動的コンテンツも可能。
  • EBS BackedとS3 instance-store backed
    EBSはネットワークストレージ、instance-storeはホストの内蔵ディスクの一時間借りのようなもの。EBSはイメージとしてスナップショットが取れる、instance-storeはS3へ構成情報と一緒に取れる。EBSは有料、instance-storeは無料。EBSは不揮発性、instance-storeは揮発性※停止で消える、再起動では消えない
  • EBS backed AMIとinstance-store backed AMI
    EBSはEBSスナップショットとして保存。instance-storeはS3に保存。
  • S3マルチパートアップロード
    オブジェクトを分割して小分けにしてアップロードできるので途中で失敗しても大丈夫。並列アップロードが可能。
  • DynamoDB

NoSQL、KVSで構造がシンプルで応答が早いが検索と集計に弱い。容量を気にしなくてもよい。

本来、リージョンごとにしかログを取得できなかったがオプションとして選択するとこで利用リージョンのログをまとめて取得できるようになった。

オブジェクト単位のアクセス制御

  • S3バケットポリシー

バケット単位のアクセス制御

  •  MFA Delete

削除を行う際に、多要素認証を必須とする。(ワンタイムパスワードなど)

  • VMインポート

OVA形式のAWSへの読み込み。

Security Token Serviceの略。一時的、短期的な認証を許可するトークンを発行する。アプリの中で認証を払い出したりすることが多い。

大容量の連続データをストリーミング受信するためのフルマネージドサービス。SQSはユーザー操作が簡単。Kinesisは大容量。

  • クロスアカウント

異なるAWSアカウントのリソースの管理や操作が可能になるための機能。

  •  proxy protocol(ELB)

ELBは、アクセス元情報はhttpもしくはhttps通信しか取得できなかったが、全てのTCP通信で可能となった。

  •  クロスゾーン負荷分散

ELBの負荷分散は分散先のAZに関わらず均等だったが、AZごとの考慮が及ぶのがクロスゾーン負荷分散。

AZ-aに5台、AZ-bに1台へ負荷分散するとするとAZ-bの一台にはAZ-aのある一台へのアクセスと比較して5倍となってしまっていたのが解消される。

  •  Import/Export

ポータブルデバイスを利用したオンプレミスデータの移行。Snowballなど。

  •  Aurora

MySQL互換のデータベース。性能が市販のDBと同等に高い。

ストアボリュームは、オンプレミス側のボリュームを丸ごとS3に保存。同期するイメージ。

キャッシュ型ボリュームは、アクセスの多い一部をオンプレミスに残し、多くをS3へ保存。

ファイルゲートウェイは、S3をNFSマウント可能。