inode使用率をcloudwatchになげるスクリプト(mon-put-data)

■inodeをcloudwatchに出力するスクリプト

環境変数、アクセスキーとかは適宜変更が必要

 

スクリプト

#!/bin/bash
##############################################
# スクリプト名 : inode_cloudwatch.sh
# 機能概要 : inodeデータをcloudwatchに出力
# 実行ユーザ : root
# 特記事項 :
##############################################
# 変数設定
##############################################
export JAVA_HOME=○○
export EC2_REGION=ap-northeast-1
export AWS_CLOUDWATCH_HOME=/○○/○○
export PATH=$PATH:$AWS_CLOUDWATCH_HOME/bin
export AWS_CREDENTIAL_FILE=/○○/○○/○○/.keyfile/aws.properties

InstanceId=`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id`

# inode check
inodeUtilzation=`df -i | awk 'NR==2' | awk '{print $5}' | sed -e 's/%//g'`
mon-put-data --metric-name "inodeUtilization" --namespace "Custom Metrix" --dimensions "InstanceId=$InstanceId" --value "$inodeUtilzation" --unit "Percent"

XAResouce勉強メモ

https://access.redhat.com/solutions/18182
■問題
Could not find new XAResource to use for recovering non-serializable XAResourceがログに出る。

■原因
XA transactionがコミットと準備の間で落ちてる。
トランザクションリカバリマネージャは、この疑いのあるトランザクションを解決しようとするけど、
適切なXAResourceがみつからず、そのためログに出てるよ。

■解決
XA resourceのリカバリ設定をする。

 

https://access.redhat.com/solutions/27402
■問題
ロールバックトランザクションリカバリはどう関係しているのか?

■解決策
通常のロールバックとJBossTSのトランザクションリカバリマネージャが実施するやつを混同するな。
ロールバックはいろんな理由で起きる。トランザクションリカバリは、ロールバックに巻き込まれないから。

JossTSのトランザクションリカバリマネージャはXA transactionsで処理するよ。全てのリソースが準備されているやつ、かつ
コミットのフェーズで不幸にも落ちた何かを処理するよ。

 

https://access.redhat.com/solutions/60858
■問題
<xa-datasource>の設定について、
どうやってJDBCトランザクションリカバリの無効化できる?

■解決策
In XA datasourceの設定

設定ファイル deploy/*-ds.xml
設定項目<xa-datasource>
<no-recover>true</no-recover>

注意:
TxConnectionManager service configuration <tx-connection-factory>
の場合、トランザクションリカバリ無効化はできない。

https://access.redhat.com/articles/216083
ディザスタリカバリ設定について
割愛

 

勉強メモ01

本日の勉強メモ。

 

■CNAMEレコードとAレコードの違い

CNAMEは、特定のホスト(FQDN)を別のホスト(FQDN)に転送する時のレコード

Aレコードは、ホスト(FQDN)とサーバーを識別するグローバルIPアドレスの関連づけを定義するレコード。

ELB は、CNAME しか登録できない。なぜか。↓

ドメイン名を使ってEC2を運用していたら、ELBのスケールアウトで苦労した話 - MUGENUP技術ブログ

 

SSH 接続の仕組みとAWS のSGとACLの違い

AWSssh接続する時に必要な知識

SSHの仕組み!ぼんやりとした理解だったものをすっきりさせようの会 - nigoblog

Amazon VPCのネットワークACLについて | Developers.IO

 

SSLの仕組み

図解で学ぶネットワークの基礎:SSL編 - 図解で学ぶネットワークの基礎:SSL編:ITpro

公開鍵と秘密鍵をわかりやすく教えてください。使い方、発信者が秘密鍵... - Yahoo!知恵袋

デジタル証明書の仕組み

 

SSL通信の機能

①データの暗号化

②サーバの認証

SSLの位置

アプリ→SSLTCP→IP→物理→IP→TCPSSLアプリ

 ◇共通鍵方式と公開鍵方式

◇認証

①CA

証明内容をハッシュ

ハッシュした値をCAの秘密鍵(署名鍵)で暗号化し、署名とする

 ②クライアント

証明内容をハッシュ

署名をCAの公開鍵(検証鍵)で復号し、ハッシュ値が同じか確認

 

 

 

Pre-Warming についてメモ

Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services

 

 

Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services

 

Pre-Warming the Load Balancer

Amazon ELB is able to handle the vast majority of use cases for our customers without requiring "pre-warming" (configuring the load balancer to have the appropriate level of capacity based on expected traffic). In certain scenarios, such as when flash traffic is expected, or in the case where a load test cannot be configured to gradually increase traffic, we recommend that you contact us to have your load balancer "pre-warmed". We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request/response that you will be testing.

構築メモ

構築メモ

 


Fluentd を使って CloudWatch のメトリクスを Graphite で見れるようにする - Qiita

 

 


td-agentとFluentdの違い - tsunokawaのはてなダイアリー

 

td-agentはFluentdの安定版,Fluentdはルビー環境、gemとかいる。。

 

 


rpmパッケージからFluentdをインストールする | Fluentd

 

RDSシステムアップグレードに関するAWSからの案内の翻訳2

Dear Amazon RDS Customer,

RDSご利用の皆様へ

As you are aware, Amazon RDS underwent a maintenance event between 26 September 2014 and 30 September 2014 to protect your instances from any security risks associated with the now public Xen Security Advisory XSA-108 (detailed on the AWS Blog:http://aws.amazon.com/blogs/aws/ec2-maintenance-update-2).

お気づきのように、2014年9月26日から30日にpublic Xen Security Advisory XSA-108脆弱性に関連して安全性を高めるためのRDSについてメンテナンスを実施しました。

Prior to this maintenance, Amazon RDS had also announced an independent, mandatory upgrade that would require offline patching, within the window of 8 October 2014 to 28 October 2014, that would affect all MySQL and PostgreSQL instances created before 02 October 2014 00:00:01 UTC.

このメンテナスより先に、オフラインのパッチのために2014年10月2日以前に作成された全てのMySQLPostgreSQLのDBインスタンスを対象にした、2014年10月8日から28日の強制的なアップグレードを独立してアナウンスしていました。

However, the unplanned XSA-108 maintenance forced us to delay progress on this planned maintenance. We also received feedback that having two maintenance events scheduled so close to each other was overly disruptive and that RDS customers want more control over when to install updates and experience maintenance outages.

 しかし、想定していない XSA-108メンテナンスのために、我々はこの計画していたメンテナンスを遅らせる必要が出てきました。我々はこの二つのメンテナンスがあまりに破壊的なくらい近すぎるというフィードバックをもらっています。そして、RDS利用者はメンテナス時間(停電)の実施やアップデートのインストールをもっとコントロールしたいというフィードバックももらっています。

As a result of these factors, we are pushing back our dates for the mandatory RDS maintenance, and are also looking into ways to make RDS instance maintenance more controllable by you.

これらのファクターの結果、我々は強制的なRDSメンテナンスの日付を延期することにしました。またメンテナスをもっと利用者がコントロールできるように変更します。

The mandatory maintenance will now be carried out during the first quarter of 2015.

この強制的なメンテナンスは現在、2015年の初めての四半期で実施予定です。

As before, maintenance will happen during your preferred maintenance window and we will send an email containing more details about your scheduled maintenance at least one month prior to the start of maintenance.

その前に、今度のメンテナンスは、あなたがメンテナンスウィンドウで臨んだ時間にメンテナンスをするようになるでしょう。そして最低でもメンテナンス期間の開始の1か月以上前にメールを送ります。

The email will include detailed maintenance windows for each region, as well as the date after which new instances will have updates applied (that is, all instances created before that date would have to undergo the upgrades).

そのメールは各リージョンのメンテナンスウィンドウの詳細を含んでます。
メンテナンスウィンドウはアップデートを受けるはずの新しいインスタンスも同様に含んでいます(アップグレードを受けるはずの時期(??2014年10月2日??)より前に作成されたすべてのインスタンスが対象だよ。)

In addition, the email will contain information about how you can schedule the update at a time of your choosing if the time chosen by RDS isn’t optimal for you.

加えて、そのメールは、もしも指定されたRDSメンテナンスの時間が好ましくない場合にどのようにアップデートの時間を選ぶかなど情報も含んでいます。

Should you have any questions or concerns, the AWS Support Team is available on the community forums and via AWS Support.

もしももっと質問や心配があればサポートかフォーラムに質問するとよいよ

Sincerely,
Amazon Web Services

RDSシステムアップグレードに関するAWSからの案内の翻訳

Dear Amazon RDS Customer,

Amazon RDS ご利用の皆様へ

 

All Amazon RDS for MySQL and PostgreSQL database instances have been scheduled to receive mandatory system upgrade as per the schedule below during the maintenance window you defined for them. For example, if you have chosen Thursday 16:00 UTC with a duration of 30min as the maintenance window for your database instance in the US West (N. California) Region, it will receive the system upgrade on 16 October 2014 (Thursday) between 16:00 UTC and 16:30 UTC.

全てのMySQLPostgreSQL用のRDS DBインスタンスは、強制的なシステムアップグレードが計画されています。それらのスケジュールはメンテナンスウィンドウでそれぞれ時期を特定できます。例えば、もしも、あなたがUS West リージョンのDBインスタンスについて木曜日の16:00UTCからの30分間をメンテナンスウィンドウで選んだ場合、システムアップグレードが2014年10月16日の16:00UTCから16:30になります。

Please note that while the upgrade completes, your DB Instance will have an availability impact for a few minutes during your maintenance window (even if you chose “No” for the “Auto Minor Version Upgrade” option). Therefore, please cross check your maintenance window settings to ensure that they are set as per your needs using the schedule above.

アップグレードが完了するまでの間、注意してください。あなたのDBインスタンスはメンテナンスとなっている数分間の可用性へ影響があります。(たとえ、オートマイナーバージョンアップオプションをNoを選んでいたとしても)

For Multi-AZ deployments, upgrade first occurs on your standby node, followed by a failover, limiting your availability impact to typically 60 - 120 seconds. You can subscribe to Event Notifications ( http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html ) for the “Maintenance” Category to receive notifications when your instance gets upgraded.

Multi-AZ構成の対象は、アップグレードははじめスタンドバイ側DBノード()で起こり、続いてアクティブ側DBノードでシステムアップグレードが起こりフェールオーバーが起こり、通常であれば60秒から120秒使えなくなる、(可用性への制限がかかる)。あなたはシステムアップグレードが起き、メンテナンスカテゴリとなった場合のイベント通知を受けることができます。

 

Note that this maintenance schedule is only applicable for MySQL and PostgreSQL database instances. Also, any MySQL or PostgreSQL database instance created after 29 Sep 2014 00:00 UTC will already have this upgrade and will not be impacted by this maintenance.

注意:このメンテナンスのスケジュールは、MySQLPostgreSQL のDBインスタンスのみ適応される。さらに、2014年9月29日00:00UTCより後に作られたMySQLPostgreSQL のDBインスタンスは既にこのアップグレードされているため、このメンテナンスの対象外です。

Lastly, if you are using MySQL 5.6, you may want to evaluate turning on InnoDB Cache Warming ( http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.InnoDBCacheWarming) and dumping the buffer pool before the upgrade to improve read latency after your instance restarts.

最後に、もしもMySQL5.6だった場合、あなたはInnoDB Cache Warming に変更されることの評価が必要になるやも。アップグレード前のバッファプールをダンプして、インスタンスがアップグレード後再起動して読み込み遅延が改善したかを。

 

Should you have any questions or concerns, the AWS Support Team is available on the community forums and via AWS Support Portal.

質問や心配があるなら下記に質問した方がいいよ

 https://forums.aws.amazon.com/forum.jspa?forumID=60

 http://aws.amazon.com/support

Asia Pacific (Sydney)
+++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 8 Oct 2014 22:00 UTC Maintenance Schedule End Date: 15 Oct 2014 21:59 UTC

Asia Pacific (Singapore)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 13 Oct 2014 00:00 UTC Maintenance Schedule End Date: 19 Oct 2014 23:59 UTC

South America (São Paulo)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 13 Oct 2014 11:00 UTC Maintenance Schedule End Date: 20 Oct 2014 10:59 UTC

US West (N. California)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 13 Oct 2014 15:00 UTC Maintenance Schedule End Date: 20 Oct 2014 14:59 UTC

US West (Oregon)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 15 Oct 2014 15:00 UTC Maintenance Schedule End Date: 22 Oct 2014 14:59 UTC

Asia Pacific (Tokyo) Region
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 15 Oct 2014 23:00 UTC Maintenance Schedule End Date: 22 Oct 2014 22:59 UTC

EU (Ireland)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 16 Oct 2014 07:00 UTC Maintenance Schedule End Date: 23 Oct 2014 06:59 UTC

US East (N. Virginia): MySQL 5.1/5.5
+++++++++++++++++++++++++++++++++++++
Engine/Version Affected: MySQL 5.1/5.5
Maintenance Schedule Start Date: 16 Oct 2014 12:00 UTC Maintenance Schedule End Date: 23 Oct 2014 11:59 UTC

US East (N. Virginia): MySQL 5.6/PostgreSQL
+++++++++++++++++++++++++++++++++++++
Engine/Version Affected: MySQL 5.6/PostgreSQL Maintenance Schedule Start Date: 21 Oct 2014 12:00 UTC Maintenance Schedule End Date: 28 Oct 2014 11:59 UTC

China (Beijing)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 21 Oct 2014 00:00 UTC Maintenance Schedule End Date: 27 Oct 2014 23:59 UTC

GovCloud (US)
+++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 21 Oct 2014 15:00 UTC Maintenance Schedule End Date: 28 Oct 2014 14:59 UTC

Sincerely,
Amazon Web Services