VPC Peering، Split Brain با NoSQL-DB منطقه متقاطع توزیع شده

Summarize this content to 400 words in Persian Lang
انگیزه
در این آزمایش، ما آگاهانه و ناگهانی یک جداسازی شبکه را در یک پایگاه داده توزیع شده زنده ایجاد می کنیم. این سیستم به طور مساوی در دو منطقه جغرافیایی به نسبت مساوی تقسیم می شود. هر منطقه زیر مجموعه پارتیشن خود را حفظ می کند. با انجام این کار، ما می توانیم به وضوح استحکام و رفتار یک سیستم توزیع شده را در شرایط پارتیشن بندی شده درک کنیم. درک این سناریوها می تواند به معماران راه حل کمک کند تا سیستم های انعطاف پذیری را طراحی کنند که موارد مختلف پارتیشن بندی را به طور موثر مدیریت کنند.
در حالی که این مقاله بر تقسیم پارتیشن مساوی تمرکز دارد، آزمایش تقسیمهای نابرابر نیز بسیار مهم است. در سناریوی اقلیت-اکثریت، پارتیشن اکثریت به مدیریت عملیات با حد نصاب ادامه خواهد داد، در حالی که پارتیشن اقلیت ممکن است با مشکلات در دسترس بودن مواجه شود. در مقاله ای جداگانه در مورد این موضوع به تفصیل بحث خواهم کرد.
من این وبلاگ را در مجموعه ای از پنج مقاله تشکیل داده ام که هر کدام مربوط به مرحله متفاوتی از آزمایش است. هر مرحله به مجموعه ای از مهارت ها نیاز دارد. به عنوان مثال، قسمت 1، شما در حال کاوش در شبکه های خصوصی مجازی و Peering خواهید بود، در حالی که در قسمت 2، نقش یک DBA را بر عهده خواهید داشت که هر قسمت شما را با چالش های مختلف آشنا می کند.
قسمت 1 – برنامه پیام رسانی متقابل ساده
قسمت 2 – نصب Aerospike NoSQL DB به عنوان Stretch Cluster
قسمت 3 – ساخت یک برنامه پایتون برای درج داده های آزمایشی
قسمت 4 – پارتیشن بندی شبکه Split Brain
قسمت 5 – مدیریت پارتیشن سازگاری قوی
جمع کنید – بعدش چی
نمای کلی
این همان کاری است که ما قصد داریم در 5 قسمت بعدی انجام دهیم.
2 VPC غیر مرتبط در AWS ایجاد کنید، هر VPC در منطقه متفاوتی خواهد بود.
ارتباط اولیه را با استفاده از یک برنامه پیام ساده از طریق شبکه خصوصی برقرار کنید.
با تقسیم اتصال بین منطقه ای مسدود شدن ترافیک را نشان دهید.
یک پایگاه داده توزیع شده را نصب کنید که شامل 2 منطقه است و آن را به عنوان یک سیستم واحد در نظر بگیرید.
یکپارچگی داده ها را با فعال کردن ویژگی ها و قوانین سازگاری قوی تأیید کنید.
ترافیک دنیای واقعی را با استفاده از یک بارگذار ساده پایتون شبیه سازی کنید
یک پارتیشن شبکه را اجرا کنید که یک سناریوی شناخته شده تقسیم مغز ایجاد می کند.
نتایج را ارزیابی کنید.
قسمت 1: منطقه Talking Cross
انتخاب مناطق
در یک مرورگر به گوشه سمت راست بالای کنسول AWS بروید
یک منطقه منحصر به فرد را انتخاب کنید.
برای این مثال انتخاب کردیم eu-west-2لندن بودن
بررسی کنید که جفت کلید صحیح دانلود شده است، زیرا بعداً برای ورود به هاست به آنها نیاز خواهید داشت.
یک برگه جدید باز کنید و منطقه دیگری را انتخاب کنید.
برای منطقه دوم استفاده خواهیم کرد eu-west-3، که پاریس است.
مجدداً بررسی کنید که جفت کلید صحیحی را برای ورود به هاست دانلود کرده اید.
با دنبال کردن این مراحل، ما تأثیر تقسیم شبکه را بر روی پایگاه داده NoSQL توزیع شده و بین منطقه ای نشان خواهیم داد. اما قبل از آن، ما اتصالات بین منطقه ای خود را با یک ابزار پیام رسانی ساده بدون نیاز به کدگذاری برنامه آزمایش می کنیم.
VPC در منطقه لندن 🏴
از کنسول AWS، از داشبورد VPC دیدن کنید و یک VPC جدید با نام “my-vpc-london-2” با بلوک IPv4 CIDR 172.32.0.0/16 ایجاد کنید.
در مرحله بعد، ما زیرشبکهها را برای مناطق مختلف در دسترس اضافه میکنیم و یک دروازه اینترنتی جدید وصل میکنیم و همه اینها را به یک جدول مسیریابی جدید مرتبط میکنیم.
زیرشبکهها را برای هر منطقه در دسترس در VPC ایجاد کنید:
اولین منطقه در دسترس
بلوک CIDR زیرشبکه IPv4 را روی 172.32.32.0/20 تنظیم کنید.
نام زیر شبکه: my-subnet-2a
منطقه دسترسی را انتخاب کنید: eu-west-2a
منطقه در دسترس بودن دوم
بلوک CIDR زیرشبکه IPv4 را روی 172.32.16.0/20 تنظیم کنید.
نام زیر شبکه: my-subnet-2b
منطقه دسترسی را انتخاب کنید: eu-west-2b
منطقه در دسترس بودن سوم
بلوک CIDR زیرشبکه IPv4 را روی 172.32.0.0/20 تنظیم کنید.
نام زیر شبکه: my-subnet-2c
منطقه در دسترس را انتخاب کنید: eu-west-2c
در بخش VPC های شما → نقشه منابع، اکنون باید زیرشبکه های اضافه شده را مشاهده کنید.
یک دروازه اینترنتی جدید ایجاد کنید و سپس آن را به جدول مسیریابی اضافه کنید. بررسی کنید که می توانید این را در نقشه منابع ببینید.
میزبان EC2 در منطقه لندن 🏴
یک نمونه EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر
ارزش
تصویر
Canonical، Ubuntu، 22.04 LTS، amd64 Jammy image ساخته شده در 01-07-2024
نوع نمونه
t2-micro
جفت کلید
کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید.
VPC
VPC را که قبلا ایجاد کردیم انتخاب کنید.
زیر شبکه
زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید.
اختصاص خودکار IP عمومی
در تولید، احتمالاً این را غیرفعال می کنید و از جعبه پرش استفاده می کنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم.
گروه امنیتی
یک گروه امنیتی جدید به نام my-sg-1 ایجاد کنید.
قانون گروه امنیتی
یک قانون TCP سفارشی برای پورت های 3000-3003 اضافه کنید، منبع از هر کجا.
برای تأیید اینکه مرحله 1 با موفقیت انجام شده است، با استفاده از SSH و کلید مرتبط خود وارد شوید:
ssh -o IdentitiesOnly=yes -i aws-instance-key-london-2.pem ubuntu@35.177.110.209
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
تبریک میگویم، اولین منطقه شما تکمیل شد. بریم سراغ منطقه دوم، پاریس!
VPC در منطقه پاریس 🇫🇷
از تب مرورگر با منطقه پاریس انتخاب شده، به داشبورد VPC بروید و یک VPC جدید ایجاد کنید. بررسی کنید که بلوکهای CIDR با VPC لندن همپوشانی ندارند. از بلوک IPv4 CIDR 172.33.0.0/16 استفاده کنید.
در مرحله بعد، ما زیرشبکههایی را برای مناطق مختلف در دسترس اضافه میکنیم و یک دروازه اینترنتی جدید وصل میکنیم و همه اینها را به یک جدول مسیریابی جدید مرتبط میکنیم، همانطور که قبلاً انجام دادیم.
زیرشبکهها را برای هر منطقه در دسترس در VPC ایجاد کنید:
اولین منطقه در دسترس
بلوک CIDR زیرشبکه IPv4 را روی 172.33.16.0/20 تنظیم کنید.
نام زیر شبکه: my-subnet-3a
منطقه دسترسی را انتخاب کنید: eu-west-3a
منطقه در دسترس بودن دوم
بلوک CIDR زیرشبکه IPv4 را روی 172.33.0.0/20 تنظیم کنید.
نام زیر شبکه: my-subnet-3b
منطقه در دسترس را انتخاب کنید: eu-west-3b
منطقه در دسترس بودن سوم
بلوک CIDR زیرشبکه IPv4 را روی 172.33.32.0/20 تنظیم کنید.
نام زیر شبکه: my-subnet-3c
منطقه در دسترس را انتخاب کنید: eu-west-3c
یک دروازه اینترنتی جدید ایجاد کنید و سپس آن را به جدول مسیریابی اضافه کنید. بررسی کنید که می توانید این را در نقشه منابع ببینید.
میزبان EC2 در منطقه پاریس 🇫🇷
یک نمونه EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر
ارزش
تصویر
ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-20240701
نوع نمونه
t2-micro
جفت کلید
کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید.
VPC
VPC را که قبلا ایجاد کردیم انتخاب کنید.
زیر شبکه
زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید.
اختصاص خودکار IP عمومی
در تولید، احتمالاً این را غیرفعال میکنید و از جعبه پرش ایمن استفاده میکنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم.
گروه امنیتی
یک گروه امنیتی جدید به نام my-sg-1 ایجاد کنید.
قانون گروه امنیتی
یک قانون TCP سفارشی برای پورت های 3000-3003 اضافه کنید، منبع از هر کجا.
با استفاده از SSH و کلید مربوطه وارد شوید تا تأیید کنید مرحله 2 با موفقیت انجام شده است:
ssh -o IdentitiesOnly=yes -i aws-instance-key-paris-1.pem ubuntu@13.38.38.248
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
تبریک میگویم، منطقه دوم شما تکمیل شد.
همتاسازی شبکه – شبکه کشیده شده
نمودار زیر نشان می دهد که ما قصد داریم با شبکه بین منطقه ای خود به چه چیزی برسیم. ما از همتاسازی VPC AWS برای دستیابی به این هدف یکپارچه استفاده خواهیم کرد. ما آزمایش خواهیم کرد که می توانیم با یک ابزار شبکه ساده و در عین حال قدرتمند به هر منطقه دسترسی پیدا کنیم.
منطقه پاریس 🇫🇷
در بخش VPC های شما ← اتصالات همتا، یک اتصال همتا جدید ایجاد کنید.
نام آن را “my-pc-to-london-1″ بگذارید.
به عنوان شناسه VPC (درخواست کننده)، VPC را که قبلا ایجاد کردیم انتخاب کنید.
VPC دیگری را برای همتا کردن در منطقه دیگر انتخاب کنید. در مثال ما، لندن (eu-west-2) است. شناسه VPC را برای VPC در لندن وارد کنید.
به VPC های پاریس بروید
جدول مسیریابی را به روز کنید:
هدف: همتاسازی VPC
مقصد: لندن CIDR 172.32.0.0/16
منطقه لندن 🏴🏧
به VPC های لندن ← Peering Connections بروید و درخواست ارائه شده از VPC پاریس را بپذیرید. ممکن است از شما خواسته شود جدول مسیریابی را به روز کنید. اگر چنین است، آن را بپذیرید.
جدول مسیریابی را به روز کنید:
هدف: همتاسازی VPC
مقصد: پاریس CIDR 172.33.0.0/16
پیام «چت» (با استفاده از nc نت کت)
از نمونه EC2 لندن، یک را شروع کنید nc سرور در پورت 3000 با سوئیچ های زیر:
nc -l -k -p 3000
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
از نمونه پاریس EC2، یک اتصال مشتری به سرور لندن برقرار کنید:
nc 172.32.34.147 3000
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
اکنون می توانید چت را شروع کنید زیرا تمام پیام های شما به معنای واقعی کلمه در سراسر کانال ارسال می شود!
قسمت 2: Aerospike NoSQL DB Stretch Cluster
در این بخش، یک خوشه کششی 6 گره NoSQL DB ایجاد می کنیم که هر ناحیه دارای 3 گره است. نمودار زیر پیکربندی خوشه کششی را نشان می دهد که در آن هر گره با گره دیگری به هم متصل می شود. به دلیل همتاسازی VPC، ممکن است تاخیرهای اضافی برای بهروزرسانیهای مشابه مشاهده شود، اما این موضوع برای این موضوع نگران کننده نیست.
هاست های پایگاه داده ایجاد کنید
برای هر منطقه، سه گره ایجاد کنید. VPC را که قبلاً تنظیم کرده اید انتخاب کنید، تخصیص IP عمومی را فعال کنید و از همان گروه امنیتی استفاده کنید.
پایگاه داده EC2 میزبان منطقه لندن است 🏴
نمونه 3 x EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر
ارزش
تصویر
Rocky-8-EC2-Base-8.7-20230215.0.x86_64 (ami-07d2b4d8d9980a125)
نوع نمونه
t3a.medium (نه آنچه در تولید استفاده می کنید)
جفت کلید
کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید.
VPC
VPC را که قبلا ایجاد کردیم انتخاب کنید.
زیر شبکه
زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید.
اختصاص خودکار IP عمومی
در تولید، احتمالاً این را غیرفعال می کنید و از جعبه پرش استفاده می کنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم.
گروه امنیتی
از همان گروه امنیتی قبلی استفاده کنید.
قانون گروه امنیتی
هیچ کدام تا کنون
حجم ها
حجم ریشه: 1x10GB-gp2، 1x8GB-gp3
پایگاه داده EC2 میزبان منطقه پاریس است 🇫🇷
نمونه 3 x EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر
ارزش
تصویر
Rocky-8-EC2-LVM-8.7-20230215.0.x86_64 (ami-064a83a6b9c2edb23)
نوع نمونه
t3a.medium (نه آنچه در تولید استفاده می کنید)
جفت کلید
کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید.
VPC
VPC را که قبلا ایجاد کردیم انتخاب کنید.
زیر شبکه
زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید.
اختصاص خودکار IP عمومی
در تولید، احتمالاً این را غیرفعال می کنید و از جعبه پرش استفاده می کنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم.
گروه امنیتی
از همان گروه امنیتی قبلی استفاده کنید.
قانون گروه امنیتی
هیچ کدام تا کنون
حجم ها
حجم ریشه: 1x10GB-gp2، 1x8GB-gp3
نصب Aerospike NoSQL DB
با استفاده از SSH به هر میزبان در یک منطقه وارد شوید و Aerospike را نصب کنید. در فایل زیر نظراتی برای یادآوری تغییرات خاص مورد نیاز برای هر میزبان وجود دارد. اگرچه چندین ابزار اتوماسیون در دسترس وجود دارد، ما به صورت دستی هر یک از شش گره را پیکربندی می کنیم تا کارها را ساده نگه دارند و به یادگیری کمک کنند.
اگر علاقه مند به دانستن بیشتر در مورد Aerospike هستید، به وب سایت Developer مراجعه کنید.
اگر یک کلید مجوز دارید که به عنوان فایل ویژگی نیز شناخته می شود، آن را در هاست کپی کنید.
SSH را در هر دستگاه میزبان قرار دهید و موارد زیر را اجرا کنید.
میزبان پایگاه داده EC2 در منطقه لندن 🏵
export VER=”7.1.0.0”
export TOOLS=11.0.0
export OS=el8
export ARCH=x86_64
sudo yum install java-11-openjdk.x86_64 java-11-openjdk java-11-openjdk-devel python3 openssl-devel wget git gcc maven bind-utils sysstat nc -y
SERVER_BIN=aerospike-server-enterprise_${VER}_tools-${TOOLS}_${OS}_${ARCH}
LINK=https://download.aerospike.com/artifacts/aerospike-server-enterprise/${VER}/${SERVER_BIN}.tgz
wget -q $LINK
tar -xvf ${SERVER_BIN}.tgz
NS=mydata
sudo mkdir -p /var/log/aerospike/
sudo mkdir -p /etc/aerospike/
# Zero the data disks
ls -l /dev/nvme1n1 | awk ‘{print $NF}’ | while read -r line; do sudo dd if=/dev/zero of=$line bs=1024 count=8192 oflag=direct; done
export ID=$((1 + $RANDOM % 1000))
export INDEX=A$ID
export IP=`ip a | grep 172 | awk {‘print $2’} | cut -f1 -d”https://dev.to/”`
export PIP=`dig +short myip.opendns.com @resolver1.opendns.com`
export S1IP=172.32.15.231 # another london node for IP seeding
export S2IP=172.33.16.172 # another paris node for IP seeding
export DEV1=/dev/nvme1n1 #
cat EOF> aerospike.conf
service {
proto-fd-max 15000
node-id $INDEX
cluster-name test-aerocluster.eu
transaction-max-ms 1500
log-local-time true
}
logging {
file /var/log/aerospike/aerospike.log {
context any info
}
}
network {
service {
address any
access-address $IP
alternate-access-address $PIP
port 3000
}
heartbeat {
mode mesh
address $IP
port 3002 # Heartbeat port for this node.
mesh-seed-address-port $S1IP 3002
mesh-seed-address-port $S2IP 3002
interval 150 # controls how often to send a heartbeat packet
timeout 10 # number of intervals after which a node is considered to be missing
}
fabric {
port 3001
channel-meta-recv-threads 8
}
}
security {
# enable-security true
log {
report-authentication true
report-sys-admin true
report-user-admin true
report-violation true
}
}
namespace mydata {
# How many copies of the data
replication-factor 2
# How full may the memory become before the server begins eviction
# (expiring records early)
evict-sys-memory-pct 50
# How full may the memory become before the server goes read only
stop-writes-sys-memory-pct 60
# How long (in seconds) to keep data after it is written Default days,
# use 0 to never expire/evict.
default-ttl 0
# Specify a percentage of record expiration time, read within this interval of the record’s end of life will generate a touch
# e.g. with default-ttl of 60s, a read with 12 seconds remaining will touch the record. [ 60 x ( 1 – default-read-touch-ttl-pct ) = 12 ]
default-read-touch-ttl-pct 20
# The interval at which the main expiration/eviction thread wakes up,
# to process the namespace.
nsup-period 120
# Disables eviction that may occur at cold start for this namespace only
disable-cold-start-eviction True
# Data high availability across racks
rack-id ${ID}
# SC Mode
strong-consistency true
# (optional) write-block is 8MiB in server 7.0 or later so max-record-size can be used to limit the record size.
max-record-size 128K
# storage-engine device {
# device $DEV1
#
# post-write-cache 64
# read-page-cache true
#
# # How full may the disk become before the server begins eviction
# # (expiring records early)
# evict-used-pct 45
# }
storage-engine memory {
file /opt/aerospike/ns1.dat # Location of a namespace data file on server
filesize 1G # Max size of each file in GiB. Maximum size is 2TiB
stop-writes-avail-pct 5 # (optional) stop-writes threshold as a percentage of
# devices/files size or data-size.
stop-writes-used-pct 70 # (optional) stop-writes threshold as a percentage of
# devices/files size, or data-size.
evict-used-pct 60 # (optional) eviction threshold, as a percentage of
# devices/files size, or data-size.
}
}
EOF
sudo cp aerospike.conf /etc/aerospike/aerospike.conf
cat EOF> aerospike.log.rotation
/var/log/aerospike/aerospike.log {
daily
rotate 90
dateext
compress
olddir /var/log/aerospike/
sharedscripts
postrotate
/bin/kill -HUP `pgrep -x asd`
endscript
}
EOF
sudo cp aerospike.log.rotation /etc/logrotate.d/aerospike
sudo cp features.conf /etc/aerospike/features.conf
cd $SERVER_BIN
sudo ./asinstall
sudo systemctl start aerospike
sudo systemctl status aerospike
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
احراز هویت کاربر ACL
می توانید دستور زیر را یک بار روی یک هاست اجرا کنید تا به آن اجازه دهید admin کاربر برای اضافه کردن رکورد به db. به طور معمول، شما کاربران و نقش های مختلفی را برای چنین وظایفی تنظیم می کنید، اما برای سادگی، ما از admin نقش (که برای محیط های تولید توصیه نمی شود).
asadm -Uadmin -Padmin -e “enable; manage acl grant user admin roles read-write”
asadm -Uadmin -Padmin -e “enable; manage acl grant user admin roles sys-admin”
asadm -Uadmin -Padmin -e “enable; show user”
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برای دریافت نمایی از خوشه Aerospike فعلی خود، از جمله گره هایی که اضافه کرده اید، می توانید دستور زیر را اجرا کنید. در این مرحله باید حداقل سه گره در منطقه لندن اضافه کرده باشید.
asadm -e i -Uadmin -Padmin
Seed: [(‘127.0.0.1’, 3000, None)]
Config_file: /home/rocky/.aerospike/astools.conf, /etc/aerospike/astools.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information (2024-08-12 09:44:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node| IP| Build|Migrations|~~~~~~~~~~~~~~Cluster~~~~~~~~~~~~~~~|Client| Uptime
| ID| | | |Size| Key|Integrity|Principal| Conns|
172.32.15.231:3000 | A352|172.32.15.231:3000|E-7.1.0.0| 0.000 | 3|155A640ADB8|True | A600| 7|00:08:16
172.32.4.2:3000 |*A600|172.32.4.2:3000 |E-7.1.0.0| 0.000 | 3|155A640ADB8|True | A600| 7|00:07:43
ip-172-32-5-239.eu-west-2.compute.internal:3000| A129|172.32.5.239:3000 |E-7.1.0.0| 0.000 | 3|155A640ADB8|True | A600| 7|00:09:38
Number of rows: 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Usage Information (2024-08-12 09:44:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Evictions| Stop|~System Memory~|~~~~Primary Index~~~~|~~Secondary~~~|~~~~~~~~~~~~~~~~~Storage Engine~~~~~~~~~~~~~~~~~
| | |Writes| Avail%| Evict%| Type| Used|Evict%|~~~~Index~~~~~| Type| Used|Used%|Evict%| Used|Avail%|Avail
| | | | | | | | | Type| Used| | | | | Stop%| |Stop%
mydata |172.32.15.231:3000 | 0.000 |False | 82| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.32.4.2:3000 | 0.000 |False | 82| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |ip-172-32-5-239.eu-west-2.compute.internal:3000| 0.000 |False | 81| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata | | 0.000 | | | | |0.000 B | | |0.000 B | |0.000 B |0.0 %| | | |
Number of rows: 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-12 09:44:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| |Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.15.231:3000 | 352| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.4.2:3000 | 600| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-5-239.eu-west-2.compute.internal:3000| 129| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 3
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
تبریک می گویم! شما باید هر شش گره را در خوشه کششی خود اضافه می کردید. این تنظیمات شامل سه گره ای است که شما در منطقه لندن پیکربندی کرده اید و سه گره در منطقه پاریس.
asadm -e i -Uadmin -Padmin
Seed: [(‘127.0.0.1’, 3000, None)]
Config_file: /home/rocky/.aerospike/astools.conf, /etc/aerospike/astools.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information (2024-08-12 09:56:34 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node| IP| Build|Migrations|~~~~~~~~~~~~~~~Cluster~~~~~~~~~~~~~~~|Client| Uptime
| ID| | | |Size| Key|Integrity|Principal| Conns|
172.32.15.231:3000 | A352|172.32.15.231:3000|E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:20:06
172.32.4.2:3000 | A600|172.32.4.2:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:19:33
172.32.5.239:3000 | A129|172.32.5.239:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:21:28
172.33.11.90:3000 | A70|172.33.11.90:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 6|00:00:39
172.33.8.38:3000 |*A882|172.33.8.38:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:00:46
ip-172-33-7-44.eu-west-3.compute.internal:3000| A517|172.33.7.44:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:00:39
Number of rows: 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Usage Information (2024-08-12 09:56:34 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Evictions| Stop|~System Memory~|~~~~Primary Index~~~~|~~Secondary~~~|~~~~~~~~~~~~~~~~~Storage Engine~~~~~~~~~~~~~~~~~
| | |Writes| Avail%| Evict%| Type| Used|Evict%|~~~~Index~~~~~| Type| Used|Used%|Evict%| Used|Avail%|Avail
| | | | | | | | | Type| Used| | | | | Stop%| |Stop%
mydata |172.32.15.231:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.32.4.2:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.32.5.239:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.33.11.90:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.33.8.38:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 0.000 |False | 77| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata | | 0.000 | | | | |0.000 B | | |0.000 B | |0.000 B |0.0 %| | | |
Number of rows: 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-12 09:56:34 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| |Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.15.231:3000 | 352| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.4.2:3000 | 600| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 129| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.11.90:3000 | 70| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 882| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 517| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
سازگاری قوی
برای فعال کردن قواعد Strong Consistency (SC) در Aerospike، باید چند دستور مدیریتی را اجرا کنید. این امر تقویت میکند که پایگاه داده شما یکپارچگی دقیق را در تمام گرههای خوشه حفظ میکند.
enable
manage roster stage observed ns mydata
manage recluster
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برای بررسی اینکه گره ها بخشی از فهرست هستند، موارد زیر را اجرا کنید
show racks
~Racks (2024-08-12 10:00:00 UTC)~
Namespace|Rack|Nodes
| ID|
mydata | 70|A70
mydata | 129|A129
mydata | 352|A352
mydata | 517|A517
mydata | 600|A600
mydata | 882|A882
Number of rows: 6
show roster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 10:00:03 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
172.32.5.239:3000 |A129 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.15.231:3000 |A352 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
ip-172-33-7-44.eu-west-3.compute.internal:3000|A517 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.4.2:3000 |A600 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.11.90:3000 |A70 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.8.38:3000 |*A882|mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
RACK-ID ها را ویرایش کنید
هر شش گره (سه گره در لندن و سه گره در پاریس) باید در خروجی ظاهر شوند، که نشان می دهد بخشی از فهرست خوشه فعلی هستند و به درستی پیکربندی شده اند.
اما صبر کن!
به نظر می رسد در حال حاضر شش قفسه در پیکربندی خوشه Aerospike شما نمایش داده شده است، که با تنظیم شما از 3 گره در هر منطقه و در مجموع 2 منطقه مطابقت ندارد. از آنجایی که تمام گرهها در هر ناحیه در یک زیرشبکه واحد هستند، میتوان آنها را در دو رک منطقی گروهبندی کرد.
برای تصحیح این، باید پیکربندی کلاستر را ویرایش کنید تا رکهای موجود را در تعداد مناسبی از rack-id (های) ادغام کنید. نمودار زیر را ببینید.
اقدام: خوشه را ویرایش کنید تا فقط 2 قفسه منطقی داشته باشیم.
# Login to the admin tool
asadm -Uadmin -Padmin
# show the roster
show roster
# Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 10:00:03 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
172.32.5.239:3000 |A129 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.15.231:3000 |A352 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
ip-172-33-7-44.eu-west-3.compute.internal:3000|A517 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.4.2:3000 |A600 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.11.90:3000 |A70 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.8.38:3000 |*A882|mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
Number of rows: 6
# remove the n-1 nodes from the cluster
manage roster remove nodes A882@882 A600@600 A517@517 A352@352 A129@129 ns mydata
# check the current roster should only be a single node
show roster
# Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 11:25:26 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace|Current|Pending| Observed Nodes
| ID| | Roster| Roster|
ip-172-32-5-239.eu-west-2.compute.internal:3000|A129 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.15.231:3000 |A352 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.7.44:3000 |A517 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.4.2:3000 |A600 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.11.90:3000 |*A70 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.8.38:3000 |A882 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
Number of rows: 6
# change the rack ids
manage config namespace mydata param rack-id to 32 with A129 A352 A600
manage recluster
info
manage config namespace mydata param rack-id to 33 with A70 A517 A882
manage recluster
info
manage roster stage observed A882@33,A600@32,A517@33,A352@32,A129@32,A70@33 ns mydata
manage recluster
show roster
# Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 11:31:08 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
ip-172-32-5-239.eu-west-2.compute.internal:3000|A129 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.32.15.231:3000 |A352 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.33.7.44:3000 |A517 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.32.4.2:3000 |A600 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.33.11.90:3000 |*A70 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.33.8.38:3000 |A882 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
Number of rows: 6
show racks
# Output
~Racks (2024-08-12 11:31:34 UTC)~
Namespace|Rack| Nodes
| ID|
mydata | 32|A600,A352,A129
mydata | 33|A882,A517,A70
Number of rows: 2
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
تبریک می گویم! شما با موفقیت پیکربندی قفسه را برای خوشه Aerospike بین منطقه ای خود به روز کردید. این خوشه اکنون به دقت دو قفسه منطقی را منعکس می کند – یکی برای هر منطقه. فراموش نکنید که آن را تأیید و به روز کنید rack-id مقادیر موجود در فایل پیکربندی Aerospike شما برای مطابقت با تنظیمات رک اصلاح شده. این اطمینان حاصل می کند که پیکربندی با معماری مورد نظر شما مطابقت دارد.
قسمت 3: درج چند رکورد
شما می خواهید تأیید کنید که داده ها در پایگاه داده Aerospike شما در حین انجام سناریوهای تقسیم مغز نوشته شده است. برای رسیدن به این هدف، یک برنامه پایتون پایه برای درج داده ایجاد خواهید کرد. این به شما کمک می کند تا رفتار خوشه و سازگاری داده ها را در شرایط آزمایش بررسی کنید. در زیر یک اسکریپت ساده پایتون وجود دارد که برخی از داده ها را در پایگاه داده Aerospike قرار می دهد. این اسکریپت از aerospike کتابخانه مشتری برای اتصال به خوشه و انجام عملیات داده.
هنگامی که اسکریپت پایتون ارائه شده را برای درج داده ها در پایگاه داده Aerospike خود اجرا می کنید، داده ها باید به صورت زیر ساختار یافته و ذخیره شوند. در اینجا نمونه ای از نحوه ظاهر داده های درج شده آورده شده است:
یک هاست ec2 اضافی در یکی از زیرشبکه ها برای اجرای کد خود ایجاد کنید.
aql> select * from mydata.dummy limit 10
+——+——+————–+————————+——————————————————————————————————————–+
| PK | freq | country_code | logged_by | report |
+——+——+————–+————————+——————————————————————————————————————–+
| 134 | 340 | 199 | “FJ4Z50qm1YFKLC5g98T2” | MAP(‘{“colour-scheme”:[“purple”, “magenta”], “date_mfg”:”2024-02-09″, “machine”:[“Surface”], “pixels”:524288}’) |
| 3758 | 408 | 121 | “rMyHrqM6eZcfYQCcCQFC” | MAP(‘{“colour-scheme”:[“cyan”, “brown”], “date_mfg”:”2023-10-07″, “machine”:[“Inspiron”], “pixels”:65536}’) |
| 2297 | 323 | 81 | “kDeHYVgb4QqzCPj1RkOw” | MAP(‘{“colour-scheme”:[“orange”, “green”], “date_mfg”:”2021-08-18″, “machine”:[“MacBook”], “pixels”:16777216}’) |
| 1841 | 833 | 224 | “2bedyAaZll3nPGKyty44” | MAP(‘{“colour-scheme”:[“green”, “purple”], “date_mfg”:”2022-07-02″, “machine”:[“Chromebook”], “pixels”:16777216}’) |
| 3017 | 898 | 213 | “qwGXGe6BdbUHh8ZBGGit” | MAP(‘{“colour-scheme”:[“purple”, “cyan”], “date_mfg”:”2024-06-22″, “machine”:[“ZenBook”], “pixels”:32768}’) |
| 3589 | 250 | 165 | “Od4R4ADltbWCD8budaco” | MAP(‘{“colour-scheme”:[“yellow”, “green”], “date_mfg”:”2018-08-02″, “machine”:[“ThinkPad”], “pixels”:65536}’) |
| 2432 | 796 | 133 | “DD1Evor4WGFX9yr9WVuc” | MAP(‘{“colour-scheme”:[“brown”, “cyan”], “date_mfg”:”2022-02-04″, “machine”:[“ThinkPad”], “pixels”:4194304}’) |
| 1652 | 623 | 1 | “HTkLNYHIPyYwUqtlZ883” | MAP(‘{“colour-scheme”:[“blue”, “magenta”], “date_mfg”:”2019-08-06″, “machine”:[“Latitude”], “pixels”:4096}’) |
| 970 | 348 | 91 | “Cao8qtth9x981pjkpp9M” | MAP(‘{“colour-scheme”:[“red”, “magenta”], “date_mfg”:”2019-09-14″, “machine”:[“Latitude”], “pixels”:1048576}’) |
| 2683 | 442 | 12 | “W9U9PBvCWodrTvf59FMz” | MAP(‘{“colour-scheme”:[“brown”, “blue”], “date_mfg”:”2024-01-14″, “machine”:[“Latitude”], “pixels”:2097152}’) |
+——+——+————–+————————+——————————————————————————————————————–+
10 rows in set (0.033 secs)
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برای کنترل مدت زمانی که برنامه پایتون شما باید اجرا شود و داده ها را در پایگاه داده Aerospike درج کند، دوره اجرای وقفه اسکریپت را تغییر دهید. این به شما امکان می دهد مدت زمان خاصی را برای اجرای اسکریپت تعیین کنید.
# Set a timeout value in seconds
run_for_sec = 30 # Adjust this value based on your needs
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
میزبان های بذر را برای خوشه Aerospike خود ویرایش کنید. من 1 گره از لندن و 1 گره از پاریس را انتخاب کرده ام.
hosts = [ (‘172.33.7.44’, 3000), (‘172.32.5.239’, 3000) ]
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برای نصب موفقیت آمیز کتابخانه مشتری Aerospike Python، باید اطمینان حاصل کنید که وابستگی های خاصی برآورده شده است.
python3-devel
پایتون 3.8
ساختن
به عنوان مثال از موارد زیر برای نصب استفاده کنید
sudo yum نصب python3-devel python3.8 make -y
سپس Aerospike Client Lib را با استفاده از pip نصب کنید.
sudo pip3.8 aerospike را نصب کنید
این هم کد:
import aerospike
from aerospike import exception as ex
import sys
import random
import string
from datetime import datetime, timedelta
import time
hosts = [ (‘172.33.7.44’, 3000), (‘172.32.5.239’, 3000) ] run_for_sec = 60
# Sleep function to pause execution for a specified number of milliseconds
def sleep_ms(milliseconds):
time.sleep(milliseconds / 1000.0)
# Function to generate a list of random dates within a specified range
def generate_random_dates(num_dates):
start_date = datetime(2018, 1, 1) # Start date
end_date = datetime(2024, 8, 31) # End date
date_range = end_date – start_date # Calculate date range
random_dates = []
for _ in range(num_dates):
random_days = random.randint(0, date_range.days) # Generate random number of days
random_date = start_date + timedelta(days=random_days) # Add random days to start date
random_dates.append(random_date)
return random_dates
# Function to generate a random username of a given length
def generate_username(length):
characters = string.ascii_letters + string.digits # Pool of characters
username = ”.join(random.choice(characters) for _ in range(length))
return username
# Function to generate a list of random colors from a predefined set
def generate_random_colors(num_colors):
colors = [‘red’, ‘blue’, ‘green’, ‘yellow’, ‘orange’, ‘purple’, ‘pink’, ‘brown’, ‘cyan’, ‘magenta’]
random_colors = random.choices(colors, k=num_colors)
return random_colors
# Function to generate a list of random computer names from a predefined set
def generate_computer_names(num_computers):
computer_types = [‘MacBook’, ‘ThinkPad’, ‘Chromebook’, ‘Surface’, ‘Latitude’, ‘Surface Book’, ‘Alienware’, ‘ZenBook’, ‘Inspiron’, ‘Pavilion’]
names = random.sample(computer_types, num_computers)
return names
# Configuration for Aerospike client
config = {
‘hosts’: hosts, # Aerospike cluster hosts
‘user’: “admin”,
‘password’: “admin”
}
namespace = ‘mydata’
set = ‘dummy’
try:
# Connect to Aerospike client
client = aerospike.client(config).connect()
print(“Connected to Server”)
# Create new write policy
write_policy = {‘key’: aerospike.POLICY_KEY_SEND}
# Set a timeout value in seconds
timeout = run_for_sec # Adjust this value based on your needs
# Define the start time
start_time = time.time()
count = 0
while True:
# Generate a random key
key = (namespace, set, random.randint(0, 4095))
# Generate random data for bins
number_sightings = random.randint(0, 1000)
cc = random.randint(0, 252)
user = generate_username(20)
date_made = generate_random_dates(1)
data = {
‘machine’: generate_computer_names(1),
‘pixels’: 2 ** random.randint(12, 24),
‘colour-scheme’: generate_random_colors(2),
‘date_mfg’: date_made[0].strftime(“%Y-%m-%d”)
}
# Create the bins
bins = {
‘freq’: number_sightings,
‘country_code’: cc,
‘logged_by’: user,
‘report’: data,
}
# Put the record into the Aerospike database
client.put(key, bins, policy=write_policy)
count = count + 1
# Check if the current time has exceeded the timeout
if time.time() – start_time > timeout:
print(“Duration reached. Records[r/u]:”,count)
break
# Sleep for 200 milliseconds
sleep_ms(200)
# Close the client connection
client.close()
except ex.ClientError as e:
# Handle client errors
print(“Error: {0} [{1}]”.format(e.msg, e.code))
sys.exit(1)
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
اطمینان حاصل کنید که برنامه پایتون شما برای مدت طولانی در پسزمینه اجرا میشود و به شما امکان میدهد آزمایشها و سناریوهای مختلف را شبیهسازی کنید.
python3.8 clientApp.py
قسمت 4: تقسیم مغز
در اینجا تصویری از سناریوی تقسیم مغز در یک سیستم داده توزیع شده ارائه شده است. این تصویر نشان می دهد که چگونه دو نیمه از یک سیستم داده (منطقه پاریس و منطقه لندن) ممکن است به دلیل جدایی شبکه از هم جدا شوند و به طور مستقل شروع به کار کنند. حتی ممکن است برخی فکر کنند که جالب است!
درک سازگاری قوی در Aerospike
در زمینه سیستم های پایگاه داده، ثبات قوی (SC) یک مفهوم حیاتی است، به ویژه در هنگام برخورد با سناریوهایی مانند شرایط تقسیم مغز. یک سناریوی تقسیم مغز زمانی اتفاق میافتد که یک پارتیشن شبکه، خوشه پایگاه داده را به دو یا چند پارتیشن تقسیم میکند که به طور بالقوه منجر به ناسازگاری دادهها میشود.
حالت سازگاری قوی Aerospike برای مقابله با چنین چالشهایی طراحی شده است و اطمینان حاصل میکند که همه نوشتهها در یک رکورد به ترتیب دقیق و متوالی اعمال میشوند. این تضمین میکند که هیچ نوشتهای مرتب یا نادیده گرفته میشود و در نتیجه هیچ دادهای از بین نمیرود.
در اینجا نگاهی عمیق تر به نحوه عملکرد قوام و اهمیت آن داریم:
ویژگی های کلیدی سازگاری قوی
متوالی می نویسد:همه نوشتهها در یک رکورد به ترتیبی که دریافت میشوند اعمال میشوند. این تضمین می کند که وضعیت رکورد در تمام گره های خوشه قابل پیش بینی و سازگار است.
بدون از دست دادن اطلاعات: حالت Aerospike SC تضمین می کند که داده ها از بین نمی روند، حتی در صورت خرابی پارتیشن های شبکه یا گره ها. با این حال، استثنائات نادری وجود دارد، مانند خرابی همزمان سخت افزار در گره های مختلف، که به طور بالقوه می تواند منجر به از دست رفتن داده ها شود.
تعهد بر اساس حد نصاب: نوشتن تنها زمانی موفق در نظر گرفته می شود که نصابی از گره ها عملیات نوشتن را تایید کنند. این بدان معنی است که اکثر گره ها باید در مورد نوشتن به توافق برسند و از ثبات داده ها حتی در صورت وجود خرابی گره ها یا مشکلات شبکه اطمینان حاصل کنند.
سازگاری فوری: به محض تایید یک عملیات نوشتن، تمام عملیات خواندن بعدی این نوشتن را منعکس می کنند. این در تضاد با ثبات نهایی است، جایی که خواندن ممکن است به طور موقت داده های قدیمی را بازگرداند.
ارزیابی سازگاری قوی در سناریوهای دوشاخه مغز
در طول یک سناریوی تقسیم مغز، پارتیشن شبکه می تواند به خوشه های جدا شده از گره ها منجر شود. ارزیابی رفتار Aerospike در چنین شرایطی برای درک استحکام حالت SC آن بسیار مهم است. در اینجا نحوه کمک به حالت SC آمده است:
عملیات را بنویسید: در یک سناریوی تقسیم مغز، نوشته ها فقط توسط گره هایی که یک پارتیشن اکثریت را تشکیل می دهند قابل پردازش هستند. این امر از نوشتن متناقض در یک رکورد از پارتیشن های مختلف جلوگیری می کند و یکپارچگی داده ها را حفظ می کند.
عملیات را بخوانید: Reads همیشه آخرین نوشتههایی را که توسط اکثر گرهها تایید شده است، برمیگرداند. اگر یک گره در یک پارتیشن اقلیت ایزوله شود، داده های قدیمی را به مشتریان ارائه نمی دهد.
آشتی پس از بهبودی: هنگامی که پارتیشن شبکه حل شد، Aerospike از حالت SC برای تطبیق هر حالت واگرا استفاده می کند. سیستم تضمین میکند که وضعیت رکوردها در تمام گرهها، بر اساس اکثر نوشتههایی که در طول پارتیشن انجام شدهاند، سازگار است.
نحوه ایجاد Split Brain
تصویر زیر نشان می دهد که شبکه کلی بین 2 منطقه و زیرشبکه های مربوط به آنها تقسیم شده است. در هر زیرشبکه، زیرخوشه اکنون دیدگاه خاص خود را از جهان دارد. هر زیرخوشه فقط با گره های داخل زیرشبکه خود ارتباط برقرار می کند.
برای شبیه سازی تقسیم شبکه بین مناطق در AWS، وارد کنسول AWS پاریس شوید. توجه داشته باشید که منبع روی تنظیم شده است 0.0.0.0/0، به این معنی که اتصالات را می توان از هر جایی برقرار کرد.این پیکربندی به ترافیک از هر آدرس IP اجازه دسترسی به این پورت ها را می دهد.
برای شبیه سازی تقسیم شبکه، باید ترافیک را محدود کنید تا فقط گره های درون یک زیرشبکه یا منطقه بتوانند با هم ارتباط برقرار کنند. به عنوان مثال، می توانید منبع را به بلوک CIDR خاص زیر شبکه خود تغییر دهید یا به خود گروه امنیتی ارجاع دهید. با اعمال این تغییرات، اطمینان حاصل کنید که:
گره ها در منطقه پاریس می توانند با گره ها در هر دو منطقه پاریس و لندن ارتباط برقرار کنند.
گره ها در منطقه لندن فقط می توانند با سایر گره های داخل منطقه لندن ارتباط برقرار کنند.
این پیکربندی به طور موثر یک تقسیم شبکه را شبیه سازی می کند که در آن زیر خوشه لندن از پاریس جدا شده است، در حالی که پاریس هنوز می تواند با هر دو منطقه تعامل داشته باشد.
با بررسی این جزئیات، مشخص می شود که تعداد رکوردها در لندن به دنبال جدایی شبکه به نصف کاهش یافته است.
قبل از رکوردهای 940 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 15:17:18 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.4.2:3000 | 32| 2| 0.000 |165.000 | 92.000 | 73.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |162.000 | 88.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.11.90:3000 | 33| 2| 0.000 |148.000 | 77.000 | 71.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.7.44:3000 | 33| 2| 0.000 |152.000 | 65.000 | 87.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |170.000 | 82.000 | 88.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |143.000 | 66.000 | 77.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |940.000 |470.000 |470.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
بعد از 470 رکورد 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 15:33:09 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.33.11.90:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.7.44:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.8.38:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.32.4.2:3000 | 32| 2| 0.000 |165.000 | 92.000 | 73.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |162.000 | 88.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |143.000 | 66.000 | 77.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |470.000 |246.000 |224.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
همانطور که می بینیم، گره های پاریس 🇫🇷 هیچ تغییری در تعداد رکوردها یا وضعیت آنها تجربه نکرده اند. این به این دلیل است که بنادر لندن هنوز به روی منابع باز هستند 0.0.0.0/0، امکان ارتباط بین مناطق را فراهم می کند.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 15:53:59 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.15.231:3000 | 32| 2| 0.000 |143.000 | 66.000 | 77.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.4.2:3000 | 32| 2| 0.000 |165.000 | 92.000 | 73.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |162.000 | 88.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.11.90:3000 | 33| 2| 0.000 |148.000 | 77.000 | 71.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |170.000 | 82.000 | 88.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |152.000 | 65.000 | 87.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |940.000 |470.000 |470.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
Admin>
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برنامه پایتون خود را از زیر شبکه ای در لندن اجرا کنید تا داده های ورودی بیشتری را از منطقه دیگری شبیه سازی کنید. به یاد بیاورید که داده های قبلی ما از پاریس ایجاد شده است.
قوانین ورودی گروه امنیتی لندن را تغییر دهید تا ترافیک فقط از زیرشبکه لندن مجاز باشد و تمام ترافیک خارجی از جمله ترافیک پاریس مسدود شود. با منزوی کردن لندن از پاریس، شما با موفقیت یک سناریوی کامل مغز را ایجاد کرده اید. این تنظیمات به درک اینکه چگونه پارتیشنهای شبکه بر توزیع داده و ارتباطات خوشهای در یک محیط پایگاه داده توزیع شده مانند Aerospike تأثیر میگذارند کمک میکند.
بیایید نتایج را ببینیم asadm، ابزار مدیریت CLI Aerospike.
لندن 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:18:29 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.33.11.90:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.7.44:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.8.38:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.32.4.2:3000 | 32| 2| 0.000 |481.000 |155.000 |171.000 | 155.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |485.000 |178.000 |149.000 | 158.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |454.000 |147.000 |160.000 | 147.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.420 K|480.000 |480.000 | 460.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
پاریس 🇫🇷
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:18:16 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.15.231:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.4.2:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.5.239:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.11.90:3000 | 33| 2| 0.000 |471.000 |165.000 |156.000 | 150.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |463.000 |153.000 |154.000 | 156.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |466.000 |142.000 |150.000 | 174.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.400 K|460.000 |460.000 | 480.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برنامه مشتری مستقر در لندن را اجرا کنید اکنون یک پارتیشن شبکه کامل داریم. توجه کنید که چگونه قبل از خراب شدن، چند رکورد برای پارتیشن هایی که دارد می نویسد.
python3.6 aerospike-client.py
Connected to Server
Error: Node not found for partition mydata:3773 [-8]
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
لندن 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:33:08 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.33.11.90:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.7.44:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.8.38:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.32.4.2:3000 | 32| 2| 0.000 |483.000 |156.000 |172.000 | 155.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |487.000 |179.000 |150.000 | 158.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |454.000 |147.000 |160.000 | 147.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.424 K|482.000 |482.000 | 460.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
پاریس 🇫🇷 – ما انتظار هیچ تغییری در تعداد رکورد نداریم زیرا نمی توانیم به پاریس برسیم
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:34:00 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.15.231:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.4.2:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.5.239:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.11.90:3000 | 33| 2| 0.000 |471.000 |165.000 |156.000 | 150.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |463.000 |153.000 |154.000 | 156.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |466.000 |142.000 |150.000 | 174.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.400 K|460.000 |460.000 | 480.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
به طور خلاصه، ما یک تقسیم یکنواخت از گره ها در هر زیرخوشه داریم و هر کدام آماده و در حال اجرا هستند اما فقط برای پارتیشن هایی که دارند.
مشاهدات کلیدی:
حتی اسپلیت: هر منطقه به طور مستقل عمل می کند و فقط پارتیشن هایی را که در اختیار دارد مدیریت می کند.
مالکیت پارتیشن: هر منطقه 50 درصد از کل پارتیشن ها را مدیریت می کند. این بدان معناست که پاریس نیمی از پارتیشن ها را اداره می کند و لندن نیمی دیگر را اداره می کند.
پاریس 🇫🇷
Admin> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-14 16:35:12 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
~~ |172.32.15.231:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.4.2:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.5.239:3000 | ~~| ~~| ~~| ~~| ~~
~~ | | | ~~| ~~| ~~| ~~
mydata |172.33.11.90:3000 |3CF08B51D327| 682| 700| 2048| 0
mydata |172.33.8.38:3000 |3CF08B51D327| 683| 669| 2048| 0
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000|3CF08B51D327| 683| 679| 2048| 0
mydata | | | 2048| 2048| 6144| 0
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
توزیع پارتیشن: show pmap فرمان تأیید می کند که پارتیشن ها به طور مساوی بین مناطق پاریس و لندن تقسیم شده اند. گرههای هر منطقه سهم مساوی از پارتیشنها را مدیریت میکنند که با جداسازی شبکه که ما پیادهسازی کردهایم همسو است.
عملیات خوشه: هر دو خوشه (پاریس و لندن) کاملاً عملیاتی هستند اما فقط برای پارتیشن هایی که در حال حاضر دارند. این نشان می دهد که چگونه مالکیت پارتیشن و توزیع داده حتی در طول یک تقسیم شبکه حفظ می شود.
با تجزیه و تحلیل این خروجی فرمان، واضح است که هر زیرخوشه در محدوده پارتیشن خود به درستی عمل می کند، که تأثیر پارتیشن شبکه بر مدیریت پارتیشن پایگاه داده Aerospike را نشان می دهد.
بازیابی پیکربندی پارتیشن شبکه
برای حل پارتیشن شبکه و بازیابی اتصال کامل، باید تغییرات قبلی قوانین گروه امنیتی ایجاد شده را لغو کنید و قوانین ورودی را دوباره تنظیم کنید تا ترافیک از همه منابع مجاز باشد (0.0.0.0/0).
نقشه پارتیشن: پس از رفع محدودیت ها، show pmap دستور باید نشان دهد که تمام پارتیشن های 4096 به درستی در سراسر خوشه مدیریت می شوند، که نشان می دهد داده ها اکنون به طور کامل توزیع شده و در دسترس هستند.
ارتباط گره: همه گره ها باید فعال باشند و با موفقیت با یکدیگر ضربان قلب کنند.
با دنبال کردن این مراحل، خوشه Aerospike را به حالت عملیاتی کامل آن بازیابی کردهاید، و مطمئن شوید که همه گرهها میتوانند با هم ارتباط برقرار کنند و توزیع دادهها در کل سیستم سازگار است.
Admin> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-14 16:46:53 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
mydata |172.32.15.231:3000 |4A4F30116D58| 683| 682| 0| 0
mydata |172.32.4.2:3000 |4A4F30116D58| 683| 683| 0| 0
mydata |172.32.5.239:3000 |4A4F30116D58| 682| 683| 0| 0
mydata |172.33.11.90:3000 |4A4F30116D58| 682| 683| 0| 0
mydata |172.33.8.38:3000 |4A4F30116D58| 683| 683| 0| 0
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000|4A4F30116D58| 683| 682| 0| 0
mydata | | | 4096| 4096| 0| 0
Number of rows: 6
Admin> i
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:46:58 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~Pending Migrates~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica| Tx| Rx
mydata |172.32.15.231:3000 | 32| 2| 0.000 |434.000 |147.000 |147.000 | 140.000 |0.000 |0.000 | 0.000 |431.000 |102.000
mydata |172.32.4.2:3000 | 32| 2| 0.000 |461.000 |156.000 |155.000 | 150.000 |0.000 |0.000 | 0.000 |423.000 |593.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |434.000 |179.000 |158.000 | 97.000 |0.000 |0.000 | 0.000 |425.000 |593.000
mydata |172.33.11.90:3000 | 33| 2| 0.000 |436.000 |165.000 |150.000 | 121.000 |0.000 |0.000 | 0.000 |440.000 |422.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |446.000 |153.000 |156.000 | 137.000 |0.000 |0.000 | 0.000 |426.000 |440.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |446.000 |142.000 |174.000 | 130.000 |0.000 |0.000 | 0.000 |425.000 |418.000
mydata | | | | 0.000 | 2.657 K|942.000 |940.000 | 775.000 |0.000 |0.000 | 0.000 | 2.570 K| 2.568 K
Number of rows: 6
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
بخش 5: درک مدیریت پارتیشن در سازگاری قوی
با درک اینکه Aerospike چگونه پارتیشنها را تحت سازگاری قوی (SC) نگهداری میکند، توسعهدهندگان برنامهها و معماران راهحل میتوانند سیستمهای خود را برای مدیریت پارتیشنهای شبکه و حفظ یکپارچگی دادهها به طور موثر طراحی کنند. در اینجا نحوه استفاده از این دانش آمده است:
نکات کلیدی در مورد مدیریت پارتیشن Aerospike
ضمانتهای سازگاری قوی:
حالت SC Aerospike تضمین میکند که همه نوشتهها در یک رکورد به ترتیب خاصی اعمال میشوند.
این بدان معنی است که حتی در یک پارتیشن شبکه یا سناریوی تقسیم مغزی، تا زمانی که الزامات مالکیت پارتیشن و حد نصاب برآورده شود، سازگاری داده ها حفظ می شود.
مالکیت پارتیشن:
هر گره در خوشه Aerospike بخشی از پارتیشن ها را مدیریت می کند. در طول یک تقسیم شبکه، گرهها در هر منطقه فقط پارتیشنهایی را که دارند مدیریت میکنند.
این مالکیت پارتیشن کمک می کند تا اطمینان حاصل شود که داده ها به طور مداوم در هر زیر مجموعه پارتیشن مدیریت می شوند.
توزیع داده ها:
در یک سیستم توزیع شده مانند Aerospike، داده ها به پارتیشن ها تقسیم می شوند و بین گره ها توزیع می شوند. در طول یک تقسیم، گره ها در هر منطقه به مدیریت و سرویس پارتیشن های خود ادامه می دهند. این رویکرد پارتیشن محور به حفظ تداوم عملیات حتی زمانی که بخش هایی از شبکه ایزوله هستند کمک می کند.
مدیریت پارتیشن های شبکه:
هنگام طراحی سیستم ها با Aerospike، مهم است که احتمال پارتیشن های شبکه را در نظر بگیرید. درک اینکه چگونه پارتیشن ها مدیریت می شوند و چگونه سازگاری قوی حفظ می شود، امکان برنامه ریزی و استراتژی های کاهش بهتر را برای مدیریت چنین سناریوهایی فراهم می کند.
ملاحظات طراحی اپلیکیشن:
افزونگی داده ها: بررسی کنید که داده ها در چندین گره تکثیر شوند تا در صورت خرابی گره یا منطقه از از دست رفتن داده ها جلوگیری شود.
پیکربندی حد نصاب: تنظیمات حد نصاب را برای تعادل بین عملکرد و سازگاری داده ها، با در نظر گرفتن پتانسیل پارتیشن های شبکه، پیکربندی کنید.
نظارت و هشدار: اجرای مکانیزم های نظارت و هشدار قوی برای شناسایی و پاسخگویی سریع به پارتیشن های شبکه و سناریوهای تقسیم مغز.
معماری راه حل:
معماری را طوری طراحی کنید که تاثیر پارتیشن های شبکه را به حداقل برساند.
این شامل پیکربندی شبکه و تنظیمات امنیتی برای کنترل دسترسی بین مناطق و حصول اطمینان از اینکه سیستم میتواند پارتیشنها را به خوبی و بدون تناقض دادههای قابل توجه اداره کند.
با گنجاندن این ملاحظات در طراحی برنامه و معماری راه حل خود، می توانید از ویژگی های سازگاری قوی Aerospike برای ایجاد سیستم های مقاوم و مقاوم در برابر خطا استفاده کنید که یکپارچگی داده ها را حتی در شرایط پیچیده شبکه حفظ می کند.
بالاخره: بعدش چی؟
بررسی سناریوهای مختلف پارتیشن شبکه
در این مقاله، بررسی کردیم که چگونه یک تقسیم شبکه (تقسیم مغز) می تواند بر سیستم داده های توزیع شده تأثیر بگذارد. ما در ابتدا بر تقسیم مساوی در دو منطقه تمرکز کردیم، اما جایگشت های متعددی از پارتیشن های شبکه وجود دارد که می تواند نتایج جالب و متنوعی را به همراه داشته باشد. در اینجا به چند مورد از این سناریوها می پردازیم.
الف: تقسیم ناهموار زیرشبکه در یک منطقه
پیکربندی:
منطقه لندن: 6 گره (2 گره در هر 3 زیرشبکه)
منطقه پاریس: 6 گره (2 گره در هر 3 زیرشبکه)
پارتیشن شبکه:
پارتیشن به یک زیرشبکه واحد در منطقه لندن بومی سازی شده است.
نتیجه مورد انتظار:
زیرشبکه اکثریت با پارتیشن شبکه به طور مستقل عمل می کند، که منجر به تقسیم ناهموار در منطقه می شود و به احتمال زیاد همه پارتیشن های پایگاه داده فعال را خواهد داشت.
با ضریب تکرار > 1 و یک چیدمان رک منطقی به درستی پیکربندی شده، همه پارتیشن های پایگاه داده در زیرشاخه 5 زیرشبکه در دسترس خواهند بود.
گرهها در زیرشبکه منفرد به عملکرد عادی خود ادامه میدهند، اما ممکن است هیچ پارتیشن پایگاه داده فعال نداشته باشند.
ب: تقسیم ناهموار در مناطق – 2 قفسه در هر منطقه
هر منطقه شامل 2 رک است که برای سازگاری قوی با ضریب تکرار 3 پیکربندی شده اند. این ضریب تکرار تضمین می کند که یک کپی از داده ها همیشه در مرکز داده جایگزین نوشته می شود. داشتن بیش از 1 رک امکان انعطاف پذیری در برابر خرابی مرکز داده یا رک را می دهد که سناریوی واقعی تری است.
پیکربندی:
منطقه لندن: 4 گره (2 قفسه)
منطقه پاریس: 3 گره (2 قفسه)
پارتیشن شبکه:
بین دو منطقه تقسیم شود.
نتیجه مورد انتظار:
داده ها در خوشه اقلیت پاریس در حالت استراحت خواهند بود اما در دسترس نیستند
با ضریب تکرار 3 یا بیشتر و سازگاری قوی، بازنشانی فهرست به صورت دستی به گرههای موجود، سیستم را بدون از دست دادن داده به حالت آنلاین باز میگرداند.
در شرایط عادی، هنگام نوشتن یک رکورد با ضریب تکرار 3 (rf:3)، نوشتن اصلی و کپی ها می توانند در هر یک از 4 قفسه توزیع شوند. از آنجایی که هر منطقه فقط 2 قفسه دارد، حداقل یک کپی تضمین شده است که در یک رک متفاوت در منطقه دیگر نوشته شود.
ترکیب های احتمالی را در زیر مشاهده کنید:
[100,101,102][100,101,103][100,102,103][101,102,103]برای آنلاین کردن خوشه اقلیت، باید 3 گره در پاریس را دوباره اختصاص دهید.
پس از فهرستبندی مجدد دستی به گرههای باقیمانده جدید، اکنون خوشه مانند زیر عملیاتی میشود.
سی: تقسیم ناهموار در مناطق
رویداد فاجعه بار که در آن اکثر 4 گره منطقه لندن به طور دائم آفلاین می شوند. حالت خوشه چگونه به نظر می رسد و اتصال مشتری چگونه تحت تأثیر قرار می گیرد؟
پیکربندی:
منطقه لندن: 4 گره
منطقه پاریس: 3 گره
پارتیشن شبکه:
بین دو منطقه تقسیم شود.
نتیجه مورد انتظار:
داده ها در خوشه اقلیت پاریس باقی می مانند اما در دسترس نیستند.
با ضریب تکرار 2 یا بیشتر و سازگاری قوی، تنظیم مجدد فهرست به صورت دستی به گره های موجود، سیستم را بدون از دست دادن داده بازیابی می کند.
ما تمرکز دقیقی روی این سناریوی خاص خواهیم داشت زیرا چالشی جذاب را ارائه می دهد.
در حال حاضر، شما باید با راه اندازی VPC ها در دو منطقه و ایجاد یک ارتباط همتا بین آنها آشنا باشید. اگر به تجدید نظر نیاز دارید، به قسمت 1 مجموعه با عنوان “برنامه پیام رسانی ساده بین منطقه ای” مراجعه کنید.
در مرحله بعد، 4 نمونه EC2 در هر منطقه ایجاد کنید، اما Aerospike را فقط روی 7 گره نصب کنید. این یک خوشه با اندازه عجیب را تضمین می کند که برای این آزمایش بسیار مهم است. اگر در این مرحله به راهنمایی نیاز دارید، از قسمت 2 – “نصب Aerospike NoSQL DB as a Stretch Cluster” دیدن کنید. هر آنچه را که نیاز دارید در آنجا پیدا خواهید کرد.
پس از تکمیل، باید سازگاری قوی را با 2 قفسه به شماره 32 و 33 فعال کنید.
اکنون زمان درج برخی از داده های آزمایشی است. ما این را در قسمت 3 پوشش دادیم، بنابراین با خیال راحت از همان کد استفاده مجدد کنید و فقط آدرسهای میزبان اولیه را بهروزرسانی کنید.
قبل از افزودن هر گونه داده، وضعیت فعلی خوشه را بررسی کنید. در این مرحله نباید هیچ داده ای وجود داشته باشد.
# 4:3 split over 2 racks ’32’ and ’33’
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:18:31 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| |Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
با استفاده از برنامه پایتون، چند رکورد تست را وارد کنید
python3.8 app.py
Connected to Server
Timeout reached. Exiting loop.
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
برای اولین اجرا ما 271 رکورد در تمام گره ها و مناطق تقسیم شده بود. جالب است اگر رکوردهای اصلی را در رک '32' خلاصه کنید [ 35+40+33+38=146] این باید با رکوردهای prole در رک '33' برابری کند [52+53+41=146].
این به این دلیل است که ما 2 رک با ضریب تکرار 2 داریم. ما انتظار داریم که در شرایط عادی یک نوشتن در rack rx با یک کپی در rack ry نوشته شود و در سازگاری قوی ما هیچ ابهامی در مورد نوشته شدن یا ننوشتن یک رکورد را تضمین نمی کنیم. .( توجه: با ضریب تکرار 2 و یک رک منفرد با 2 یا بیشتر گره موجود است، مشتریان همچنان می توانند داده ها را با موفقیت بنویسند)
# 271 master records
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:21:31 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 | 71.000 | 35.000 | 36.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 | 71.000 | 40.000 | 31.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 | 60.000 | 33.000 | 27.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 | 69.000 | 38.000 | 31.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 | 98.000 | 46.000 | 52.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 | 88.000 | 35.000 | 53.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 | 85.000 | 44.000 | 41.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |542.000 |271.000 |271.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
ادامه دهید و داده های بیشتری را وارد کنید و شاید بررسی های حسابداری مانند بالا را امتحان کنید.
python3.8 app.py
Connected to Server
Timeout reached. Exiting loop.
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
# 517 master records
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:24:13 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 |134.000 | 68.000 | 66.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 |137.000 | 78.000 | 59.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 |110.000 | 63.000 | 47.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 |136.000 | 77.000 | 59.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 |192.000 | 79.000 |113.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |160.000 | 67.000 | 93.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |165.000 | 85.000 | 80.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.034 K|517.000 |517.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
در رک 32 چند رکورد مستر و در رک 33 چند رکورد پرول به دست آوردید؟
بن بنگ! ادامه دهید و هر 4 گره را در منطقه لندن خاموش کنید. شما asadm دستورات info و pmap باید شبیه زیر باشد:
Admin+> info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:26:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 | 33| 2| 0.000 |192.000 |0.000 |0.000 | 192.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |160.000 |0.000 |0.000 | 160.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |165.000 |0.000 |0.000 | 165.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |517.000 |0.000 |0.000 | 517.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
Admin+> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-21 12:28:14 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~
~~ | | | ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 |39A2BCE70658| 0| 0| 4096| 0
mydata |172.33.46.58:3000 |39A2BCE70658| 0| 0| 4096| 0
mydata |ip-172-33-42-240.eu-west-3.compute.internal:3000|39A2BCE70658| 0| 0| 4096| 0
mydata | | | 0| 0| 12288| 0
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
در این مرحله کلاینت شما نمی تواند به هیچ پارتیشنی دسترسی داشته باشد. برای حل این مشکل، پس از اطمینان از پایداری سیستم، باید یک فرمان اپراتور صادر کنید. در اصل، تمام گرههای رک '32' را از فهرست حذف کنید.
Admin+> manage roster remove nodes A541@32 A445@32 A333@32 A332@32 ns mydata
Node(s) successfully removed from pending-roster.
Run “manage recluster” for your changes to take affect.
Admin+> manage recluster
Successfully started recluster
Admin+> show roster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-21 12:29:03 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node ID|Namespace| Current Roster| Pending Roster| Observed Nodes
172.32.1.105:3000 |000000000000000|~~ |~~ |~~ |~~
172.32.8.190:3000 |000000000000000|~~ |~~ |~~ |~~
172.32.7.25:3000 |000000000000000|~~ |~~ |~~ |~~
172.32.0.79:3000 |000000000000000|~~ |~~ |~~ |~~
172.33.46.58:3000 |A250 |mydata |A829@33,A476@33,A250@33|A829@33,A476@33,A250@33|A829@33,A476@33,A250@33
ip-172-33-42-240.eu-west-3.compute.internal:3000|A476 |mydata |A829@33,A476@33,A250@33|A829@33,A476@33,A250@33|A829@33,A476@33,A250@33
172.33.35.102:3000 |*A829 |mydata |A829@33,A476@33,A250@33|A829@33,A476@33,A250@33|A829@33,A476@33,A250@33
Number of rows: 7
Admin+> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-21 12:29:11 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~
~~ | | | ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 |E6BE8E200C70| 1366| 1365| 0| 0
mydata |172.33.46.58:3000 |E6BE8E200C70| 1365| 1365| 0| 0
mydata |ip-172-33-42-240.eu-west-3.compute.internal:3000|E6BE8E200C70| 1365| 1366| 0| 0
mydata | | | 4096| 4096| 0| 0
Number of rows: 7
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
در این مرحله مشتری شما باید قادر به نوشتن داده باشد. با این حال، بیایید تعداد کل رکوردها را تأیید کنیم.
# After recluster we have 517 records as before
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:29:31 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 | 33| 2| 0.000 |364.000 |195.000 |169.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |331.000 |158.000 |173.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |339.000 |164.000 |175.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.034 K|517.000 |517.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
قبل از احیای قفسه '32' در لندن، داده های آزمایشی اضافی را وارد کنید.
python3.8 app.py
Connected to Server
Timeout reached. Exiting loop.
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
# We now have 778 records
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:44:51 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 | 33| 2| 0.000 |557.000 |295.000 |262.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |498.000 |250.000 |248.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |501.000 |233.000 |268.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.556 K|778.000 |778.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
اکنون به طور قابل اعتمادی به شما اطلاع داده شده است که قطعی قطع شده است، همه گرههای رک '32' را دوباره آنلاین کنید.
Admin+> manage roster stage observed A541@32,A445@32,A333@32,A332@32 ns mydata
Pending roster now contains observed nodes.
Run “manage recluster” for your changes to take affect.
Admin+> manage recluster
Successfully started recluster
Admin+> show racks
~Racks (2024-08-21 12:48:07 UTC)~~
Namespace|Rack| Nodes
| ID|
mydata | 32|A541,A445,A333,A332
mydata | 33|A829,A476,A250
Number of rows: 2
Admin+> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-21 12:48:13 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
mydata |172.32.0.79:3000 |4AC63FB091A3| 109| 915| 0| 0
mydata |172.32.1.105:3000 |4AC63FB091A3| 103| 921| 0| 0
mydata |172.32.7.25:3000 |4AC63FB091A3| 111| 913| 0| 0
mydata |172.32.8.190:3000 |4AC63FB091A3| 99| 925| 0| 0
mydata |172.33.35.102:3000 |4AC63FB091A3| 1213| 179| 0| 0
mydata |172.33.46.58:3000 |4AC63FB091A3| 1226| 185| 0| 0
mydata |ip-172-33-42-240.eu-west-3.compute.internal:3000|4AC63FB091A3| 1235| 167| 0| 0
mydata | | | 4096| 4205| 0| 0
Number of rows: 7
Admin+> show roster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-21 12:48:19 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
172.33.46.58:3000 |A250 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.8.190:3000 |A332 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.1.105:3000 |A333 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.7.25:3000 |A445 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
ip-172-33-42-240.eu-west-3.compute.internal:3000|A476 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.0.79:3000 |A541 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.33.35.102:3000 |*A829|mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
Number of rows: 7
# 778 records
Admin+> info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:49:17 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 |195.000 |100.000 | 95.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 |209.000 |115.000 | 94.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 |176.000 |102.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 |198.000 |108.000 | 90.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 |291.000 |126.000 |165.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |252.000 |104.000 |148.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |235.000 |123.000 |112.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.556 K|778.000 |778.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
وویلا! – به نظرم خوبه ما همه 778 رکوردی که انتظار داشتیم را داریم.
خودکار کردن سناریوهای پارتیشن شبکه
خودکارسازی این سناریوها می تواند در زمان صرفه جویی کرده و احتمال خطای انسانی را کاهش دهد. می توانید از اسکریپت ها و ابزارهایی مانند AWS CLI یا Terraform برای ایجاد و مدیریت این پارتیشن های شبکه استفاده کنید.
آینده: Service Mesh و Kubernetes
در مقاله بعدی، ایجاد یک سناریوی پارتیشن شبکه مشابه با استفاده از مش سرویس و گسترش یک کلاستر پایگاه داده در Kubernetes با اپراتور Aerospike Kubernetes را بررسی خواهیم کرد.
تماس و بازخورد
اگر سؤال یا پیشنهادی دارید، میتوانید به آدرس icloud.nkm@gmail.com به من مراجعه کنید.
نتیجه گیری
ما در مورد سناریوهای مختلف پارتیشن شبکه و تأثیرات بالقوه آنها بر یک سیستم داده توزیع شده بحث کرده ایم. با درک و آزمایش این سناریوها، می توانید سیستم های انعطاف پذیرتر و قوی تری طراحی کنید.
امیدوارم از خواندن این مقاله لذت برده باشید و چیزهای جدیدی یاد گرفته باشید.
انگیزه
در این آزمایش، ما آگاهانه و ناگهانی یک جداسازی شبکه را در یک پایگاه داده توزیع شده زنده ایجاد می کنیم. این سیستم به طور مساوی در دو منطقه جغرافیایی به نسبت مساوی تقسیم می شود. هر منطقه زیر مجموعه پارتیشن خود را حفظ می کند. با انجام این کار، ما می توانیم به وضوح استحکام و رفتار یک سیستم توزیع شده را در شرایط پارتیشن بندی شده درک کنیم. درک این سناریوها می تواند به معماران راه حل کمک کند تا سیستم های انعطاف پذیری را طراحی کنند که موارد مختلف پارتیشن بندی را به طور موثر مدیریت کنند.
در حالی که این مقاله بر تقسیم پارتیشن مساوی تمرکز دارد، آزمایش تقسیمهای نابرابر نیز بسیار مهم است. در سناریوی اقلیت-اکثریت، پارتیشن اکثریت به مدیریت عملیات با حد نصاب ادامه خواهد داد، در حالی که پارتیشن اقلیت ممکن است با مشکلات در دسترس بودن مواجه شود. در مقاله ای جداگانه در مورد این موضوع به تفصیل بحث خواهم کرد.
من این وبلاگ را در مجموعه ای از پنج مقاله تشکیل داده ام که هر کدام مربوط به مرحله متفاوتی از آزمایش است. هر مرحله به مجموعه ای از مهارت ها نیاز دارد. به عنوان مثال، قسمت 1، شما در حال کاوش در شبکه های خصوصی مجازی و Peering خواهید بود، در حالی که در قسمت 2، نقش یک DBA را بر عهده خواهید داشت که هر قسمت شما را با چالش های مختلف آشنا می کند.
- قسمت 1 – برنامه پیام رسانی متقابل ساده
- قسمت 2 – نصب Aerospike NoSQL DB به عنوان Stretch Cluster
- قسمت 3 – ساخت یک برنامه پایتون برای درج داده های آزمایشی
- قسمت 4 – پارتیشن بندی شبکه Split Brain
- قسمت 5 – مدیریت پارتیشن سازگاری قوی
- جمع کنید – بعدش چی
نمای کلی
این همان کاری است که ما قصد داریم در 5 قسمت بعدی انجام دهیم.
- 2 VPC غیر مرتبط در AWS ایجاد کنید، هر VPC در منطقه متفاوتی خواهد بود.
- ارتباط اولیه را با استفاده از یک برنامه پیام ساده از طریق شبکه خصوصی برقرار کنید.
- با تقسیم اتصال بین منطقه ای مسدود شدن ترافیک را نشان دهید.
- یک پایگاه داده توزیع شده را نصب کنید که شامل 2 منطقه است و آن را به عنوان یک سیستم واحد در نظر بگیرید.
- یکپارچگی داده ها را با فعال کردن ویژگی ها و قوانین سازگاری قوی تأیید کنید.
- ترافیک دنیای واقعی را با استفاده از یک بارگذار ساده پایتون شبیه سازی کنید
- یک پارتیشن شبکه را اجرا کنید که یک سناریوی شناخته شده تقسیم مغز ایجاد می کند.
- نتایج را ارزیابی کنید.
قسمت 1: منطقه Talking Cross
انتخاب مناطق
- در یک مرورگر به گوشه سمت راست بالای کنسول AWS بروید
- یک منطقه منحصر به فرد را انتخاب کنید.
- برای این مثال انتخاب کردیم
eu-west-2
لندن بودن
- برای این مثال انتخاب کردیم
- بررسی کنید که جفت کلید صحیح دانلود شده است، زیرا بعداً برای ورود به هاست به آنها نیاز خواهید داشت.
- یک برگه جدید باز کنید و منطقه دیگری را انتخاب کنید.
- برای منطقه دوم استفاده خواهیم کرد
eu-west-3
، که پاریس است.
- برای منطقه دوم استفاده خواهیم کرد
- مجدداً بررسی کنید که جفت کلید صحیحی را برای ورود به هاست دانلود کرده اید.
با دنبال کردن این مراحل، ما تأثیر تقسیم شبکه را بر روی پایگاه داده NoSQL توزیع شده و بین منطقه ای نشان خواهیم داد. اما قبل از آن، ما اتصالات بین منطقه ای خود را با یک ابزار پیام رسانی ساده بدون نیاز به کدگذاری برنامه آزمایش می کنیم.
VPC در منطقه لندن 🏴
از کنسول AWS، از داشبورد VPC دیدن کنید و یک VPC جدید با نام “my-vpc-london-2” با بلوک IPv4 CIDR 172.32.0.0/16 ایجاد کنید.
در مرحله بعد، ما زیرشبکهها را برای مناطق مختلف در دسترس اضافه میکنیم و یک دروازه اینترنتی جدید وصل میکنیم و همه اینها را به یک جدول مسیریابی جدید مرتبط میکنیم.
زیرشبکهها را برای هر منطقه در دسترس در VPC ایجاد کنید:
-
اولین منطقه در دسترس
- بلوک CIDR زیرشبکه IPv4 را روی 172.32.32.0/20 تنظیم کنید.
- نام زیر شبکه: my-subnet-2a
- منطقه دسترسی را انتخاب کنید: eu-west-2a
-
منطقه در دسترس بودن دوم
- بلوک CIDR زیرشبکه IPv4 را روی 172.32.16.0/20 تنظیم کنید.
- نام زیر شبکه: my-subnet-2b
- منطقه دسترسی را انتخاب کنید: eu-west-2b
-
منطقه در دسترس بودن سوم
- بلوک CIDR زیرشبکه IPv4 را روی 172.32.0.0/20 تنظیم کنید.
- نام زیر شبکه: my-subnet-2c
- منطقه در دسترس را انتخاب کنید: eu-west-2c
در بخش VPC های شما → نقشه منابع، اکنون باید زیرشبکه های اضافه شده را مشاهده کنید.
یک دروازه اینترنتی جدید ایجاد کنید و سپس آن را به جدول مسیریابی اضافه کنید. بررسی کنید که می توانید این را در نقشه منابع ببینید.
میزبان EC2 در منطقه لندن 🏴
یک نمونه EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر | ارزش |
---|---|
تصویر | Canonical، Ubuntu، 22.04 LTS، amd64 Jammy image ساخته شده در 01-07-2024 |
نوع نمونه | t2-micro |
جفت کلید | کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید. |
VPC | VPC را که قبلا ایجاد کردیم انتخاب کنید. |
زیر شبکه | زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید. |
اختصاص خودکار IP عمومی | در تولید، احتمالاً این را غیرفعال می کنید و از جعبه پرش استفاده می کنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم. |
گروه امنیتی | یک گروه امنیتی جدید به نام my-sg-1 ایجاد کنید. |
قانون گروه امنیتی | یک قانون TCP سفارشی برای پورت های 3000-3003 اضافه کنید، منبع از هر کجا. |
برای تأیید اینکه مرحله 1 با موفقیت انجام شده است، با استفاده از SSH و کلید مرتبط خود وارد شوید:
ssh -o IdentitiesOnly=yes -i aws-instance-key-london-2.pem ubuntu@35.177.110.209
تبریک میگویم، اولین منطقه شما تکمیل شد. بریم سراغ منطقه دوم، پاریس!
VPC در منطقه پاریس 🇫🇷
از تب مرورگر با منطقه پاریس انتخاب شده، به داشبورد VPC بروید و یک VPC جدید ایجاد کنید. بررسی کنید که بلوکهای CIDR با VPC لندن همپوشانی ندارند. از بلوک IPv4 CIDR 172.33.0.0/16 استفاده کنید.
در مرحله بعد، ما زیرشبکههایی را برای مناطق مختلف در دسترس اضافه میکنیم و یک دروازه اینترنتی جدید وصل میکنیم و همه اینها را به یک جدول مسیریابی جدید مرتبط میکنیم، همانطور که قبلاً انجام دادیم.
زیرشبکهها را برای هر منطقه در دسترس در VPC ایجاد کنید:
-
اولین منطقه در دسترس
- بلوک CIDR زیرشبکه IPv4 را روی 172.33.16.0/20 تنظیم کنید.
- نام زیر شبکه: my-subnet-3a
- منطقه دسترسی را انتخاب کنید: eu-west-3a
-
منطقه در دسترس بودن دوم
- بلوک CIDR زیرشبکه IPv4 را روی 172.33.0.0/20 تنظیم کنید.
- نام زیر شبکه: my-subnet-3b
- منطقه در دسترس را انتخاب کنید: eu-west-3b
-
منطقه در دسترس بودن سوم
- بلوک CIDR زیرشبکه IPv4 را روی 172.33.32.0/20 تنظیم کنید.
- نام زیر شبکه: my-subnet-3c
- منطقه در دسترس را انتخاب کنید: eu-west-3c
یک دروازه اینترنتی جدید ایجاد کنید و سپس آن را به جدول مسیریابی اضافه کنید. بررسی کنید که می توانید این را در نقشه منابع ببینید.
میزبان EC2 در منطقه پاریس 🇫🇷
یک نمونه EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر | ارزش |
---|---|
تصویر | ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-20240701 |
نوع نمونه | t2-micro |
جفت کلید | کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید. |
VPC | VPC را که قبلا ایجاد کردیم انتخاب کنید. |
زیر شبکه | زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید. |
اختصاص خودکار IP عمومی | در تولید، احتمالاً این را غیرفعال میکنید و از جعبه پرش ایمن استفاده میکنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم. |
گروه امنیتی | یک گروه امنیتی جدید به نام my-sg-1 ایجاد کنید. |
قانون گروه امنیتی | یک قانون TCP سفارشی برای پورت های 3000-3003 اضافه کنید، منبع از هر کجا. |
با استفاده از SSH و کلید مربوطه وارد شوید تا تأیید کنید مرحله 2 با موفقیت انجام شده است:
ssh -o IdentitiesOnly=yes -i aws-instance-key-paris-1.pem ubuntu@13.38.38.248
تبریک میگویم، منطقه دوم شما تکمیل شد.
همتاسازی شبکه – شبکه کشیده شده
نمودار زیر نشان می دهد که ما قصد داریم با شبکه بین منطقه ای خود به چه چیزی برسیم. ما از همتاسازی VPC AWS برای دستیابی به این هدف یکپارچه استفاده خواهیم کرد. ما آزمایش خواهیم کرد که می توانیم با یک ابزار شبکه ساده و در عین حال قدرتمند به هر منطقه دسترسی پیدا کنیم.
-
منطقه پاریس 🇫🇷
- در بخش VPC های شما ← اتصالات همتا، یک اتصال همتا جدید ایجاد کنید.
- نام آن را “my-pc-to-london-1” بگذارید.
- به عنوان شناسه VPC (درخواست کننده)، VPC را که قبلا ایجاد کردیم انتخاب کنید.
- VPC دیگری را برای همتا کردن در منطقه دیگر انتخاب کنید. در مثال ما، لندن (eu-west-2) است. شناسه VPC را برای VPC در لندن وارد کنید.
- به VPC های پاریس بروید
- جدول مسیریابی را به روز کنید:
- هدف: همتاسازی VPC
- مقصد: لندن CIDR 172.32.0.0/16
-
منطقه لندن 🏴🏧
- به VPC های لندن ← Peering Connections بروید و درخواست ارائه شده از VPC پاریس را بپذیرید. ممکن است از شما خواسته شود جدول مسیریابی را به روز کنید. اگر چنین است، آن را بپذیرید.
- جدول مسیریابی را به روز کنید:
- هدف: همتاسازی VPC
- مقصد: پاریس CIDR 172.33.0.0/16
پیام «چت» (با استفاده از nc
نت کت)
از نمونه EC2 لندن، یک را شروع کنید nc
سرور در پورت 3000 با سوئیچ های زیر:
nc -l -k -p 3000
از نمونه پاریس EC2، یک اتصال مشتری به سرور لندن برقرار کنید:
nc 172.32.34.147 3000
اکنون می توانید چت را شروع کنید زیرا تمام پیام های شما به معنای واقعی کلمه در سراسر کانال ارسال می شود!
قسمت 2: Aerospike NoSQL DB Stretch Cluster
در این بخش، یک خوشه کششی 6 گره NoSQL DB ایجاد می کنیم که هر ناحیه دارای 3 گره است. نمودار زیر پیکربندی خوشه کششی را نشان می دهد که در آن هر گره با گره دیگری به هم متصل می شود. به دلیل همتاسازی VPC، ممکن است تاخیرهای اضافی برای بهروزرسانیهای مشابه مشاهده شود، اما این موضوع برای این موضوع نگران کننده نیست.
هاست های پایگاه داده ایجاد کنید
برای هر منطقه، سه گره ایجاد کنید. VPC را که قبلاً تنظیم کرده اید انتخاب کنید، تخصیص IP عمومی را فعال کنید و از همان گروه امنیتی استفاده کنید.
پایگاه داده EC2 میزبان منطقه لندن است 🏴
نمونه 3 x EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر | ارزش |
---|---|
تصویر | Rocky-8-EC2-Base-8.7-20230215.0.x86_64 (ami-07d2b4d8d9980a125) |
نوع نمونه | t3a.medium (نه آنچه در تولید استفاده می کنید) |
جفت کلید | کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید. |
VPC | VPC را که قبلا ایجاد کردیم انتخاب کنید. |
زیر شبکه | زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید. |
اختصاص خودکار IP عمومی | در تولید، احتمالاً این را غیرفعال می کنید و از جعبه پرش استفاده می کنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم. |
گروه امنیتی | از همان گروه امنیتی قبلی استفاده کنید. |
قانون گروه امنیتی | هیچ کدام تا کنون |
حجم ها | حجم ریشه: 1x10GB-gp2، 1x8GB-gp3 |
پایگاه داده EC2 میزبان منطقه پاریس است 🇫🇷
نمونه 3 x EC2 را با تنظیمات زیر راه اندازی کنید:
پارامتر | ارزش |
---|---|
تصویر | Rocky-8-EC2-LVM-8.7-20230215.0.x86_64 (ami-064a83a6b9c2edb23) |
نوع نمونه | t3a.medium (نه آنچه در تولید استفاده می کنید) |
جفت کلید | کلیدی را که قبلا ایجاد کردهاید و با خیال راحت دانلود کردهاید انتخاب کنید. |
VPC | VPC را که قبلا ایجاد کردیم انتخاب کنید. |
زیر شبکه | زیرشبکهای را که قبلاً برای منطقه در دسترس بودن این میزبان ایجاد کردیم، انتخاب کنید. |
اختصاص خودکار IP عمومی | در تولید، احتمالاً این را غیرفعال می کنید و از جعبه پرش استفاده می کنید. برای سادگی، ما مستقیماً با استفاده از IP عمومی SSH می کنیم. |
گروه امنیتی | از همان گروه امنیتی قبلی استفاده کنید. |
قانون گروه امنیتی | هیچ کدام تا کنون |
حجم ها | حجم ریشه: 1x10GB-gp2، 1x8GB-gp3 |
نصب Aerospike NoSQL DB
با استفاده از SSH به هر میزبان در یک منطقه وارد شوید و Aerospike را نصب کنید. در فایل زیر نظراتی برای یادآوری تغییرات خاص مورد نیاز برای هر میزبان وجود دارد. اگرچه چندین ابزار اتوماسیون در دسترس وجود دارد، ما به صورت دستی هر یک از شش گره را پیکربندی می کنیم تا کارها را ساده نگه دارند و به یادگیری کمک کنند.
اگر علاقه مند به دانستن بیشتر در مورد Aerospike هستید، به وب سایت Developer مراجعه کنید.
- اگر یک کلید مجوز دارید که به عنوان فایل ویژگی نیز شناخته می شود، آن را در هاست کپی کنید.
- SSH را در هر دستگاه میزبان قرار دهید و موارد زیر را اجرا کنید.
میزبان پایگاه داده EC2 در منطقه لندن 🏵
export VER="7.1.0.0"
export TOOLS=11.0.0
export OS=el8
export ARCH=x86_64
sudo yum install java-11-openjdk.x86_64 java-11-openjdk java-11-openjdk-devel python3 openssl-devel wget git gcc maven bind-utils sysstat nc -y
SERVER_BIN=aerospike-server-enterprise_${VER}_tools-${TOOLS}_${OS}_${ARCH}
LINK=https://download.aerospike.com/artifacts/aerospike-server-enterprise/${VER}/${SERVER_BIN}.tgz
wget -q $LINK
tar -xvf ${SERVER_BIN}.tgz
NS=mydata
sudo mkdir -p /var/log/aerospike/
sudo mkdir -p /etc/aerospike/
# Zero the data disks
ls -l /dev/nvme1n1 | awk '{print $NF}' | while read -r line; do sudo dd if=/dev/zero of=$line bs=1024 count=8192 oflag=direct; done
export ID=$((1 + $RANDOM % 1000))
export INDEX=A$ID
export IP=`ip a | grep 172 | awk {'print $2'} | cut -f1 -d"https://dev.to/"`
export PIP=`dig +short myip.opendns.com @resolver1.opendns.com`
export S1IP=172.32.15.231 # another london node for IP seeding
export S2IP=172.33.16.172 # another paris node for IP seeding
export DEV1=/dev/nvme1n1 #
cat EOF> aerospike.conf
service {
proto-fd-max 15000
node-id $INDEX
cluster-name test-aerocluster.eu
transaction-max-ms 1500
log-local-time true
}
logging {
file /var/log/aerospike/aerospike.log {
context any info
}
}
network {
service {
address any
access-address $IP
alternate-access-address $PIP
port 3000
}
heartbeat {
mode mesh
address $IP
port 3002 # Heartbeat port for this node.
mesh-seed-address-port $S1IP 3002
mesh-seed-address-port $S2IP 3002
interval 150 # controls how often to send a heartbeat packet
timeout 10 # number of intervals after which a node is considered to be missing
}
fabric {
port 3001
channel-meta-recv-threads 8
}
}
security {
# enable-security true
log {
report-authentication true
report-sys-admin true
report-user-admin true
report-violation true
}
}
namespace mydata {
# How many copies of the data
replication-factor 2
# How full may the memory become before the server begins eviction
# (expiring records early)
evict-sys-memory-pct 50
# How full may the memory become before the server goes read only
stop-writes-sys-memory-pct 60
# How long (in seconds) to keep data after it is written Default days,
# use 0 to never expire/evict.
default-ttl 0
# Specify a percentage of record expiration time, read within this interval of the record’s end of life will generate a touch
# e.g. with default-ttl of 60s, a read with 12 seconds remaining will touch the record. [ 60 x ( 1 - default-read-touch-ttl-pct ) = 12 ]
default-read-touch-ttl-pct 20
# The interval at which the main expiration/eviction thread wakes up,
# to process the namespace.
nsup-period 120
# Disables eviction that may occur at cold start for this namespace only
disable-cold-start-eviction True
# Data high availability across racks
rack-id ${ID}
# SC Mode
strong-consistency true
# (optional) write-block is 8MiB in server 7.0 or later so max-record-size can be used to limit the record size.
max-record-size 128K
# storage-engine device {
# device $DEV1
#
# post-write-cache 64
# read-page-cache true
#
# # How full may the disk become before the server begins eviction
# # (expiring records early)
# evict-used-pct 45
# }
storage-engine memory {
file /opt/aerospike/ns1.dat # Location of a namespace data file on server
filesize 1G # Max size of each file in GiB. Maximum size is 2TiB
stop-writes-avail-pct 5 # (optional) stop-writes threshold as a percentage of
# devices/files size or data-size.
stop-writes-used-pct 70 # (optional) stop-writes threshold as a percentage of
# devices/files size, or data-size.
evict-used-pct 60 # (optional) eviction threshold, as a percentage of
# devices/files size, or data-size.
}
}
EOF
sudo cp aerospike.conf /etc/aerospike/aerospike.conf
cat EOF> aerospike.log.rotation
/var/log/aerospike/aerospike.log {
daily
rotate 90
dateext
compress
olddir /var/log/aerospike/
sharedscripts
postrotate
/bin/kill -HUP `pgrep -x asd`
endscript
}
EOF
sudo cp aerospike.log.rotation /etc/logrotate.d/aerospike
sudo cp features.conf /etc/aerospike/features.conf
cd $SERVER_BIN
sudo ./asinstall
sudo systemctl start aerospike
sudo systemctl status aerospike
احراز هویت کاربر ACL
می توانید دستور زیر را یک بار روی یک هاست اجرا کنید تا به آن اجازه دهید admin
کاربر برای اضافه کردن رکورد به db. به طور معمول، شما کاربران و نقش های مختلفی را برای چنین وظایفی تنظیم می کنید، اما برای سادگی، ما از admin
نقش (که برای محیط های تولید توصیه نمی شود).
asadm -Uadmin -Padmin -e "enable; manage acl grant user admin roles read-write"
asadm -Uadmin -Padmin -e "enable; manage acl grant user admin roles sys-admin"
asadm -Uadmin -Padmin -e "enable; show user"
برای دریافت نمایی از خوشه Aerospike فعلی خود، از جمله گره هایی که اضافه کرده اید، می توانید دستور زیر را اجرا کنید. در این مرحله باید حداقل سه گره در منطقه لندن اضافه کرده باشید.
asadm -e i -Uadmin -Padmin
Seed: [('127.0.0.1', 3000, None)]
Config_file: /home/rocky/.aerospike/astools.conf, /etc/aerospike/astools.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information (2024-08-12 09:44:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node| IP| Build|Migrations|~~~~~~~~~~~~~~Cluster~~~~~~~~~~~~~~~|Client| Uptime
| ID| | | |Size| Key|Integrity|Principal| Conns|
172.32.15.231:3000 | A352|172.32.15.231:3000|E-7.1.0.0| 0.000 | 3|155A640ADB8|True | A600| 7|00:08:16
172.32.4.2:3000 |*A600|172.32.4.2:3000 |E-7.1.0.0| 0.000 | 3|155A640ADB8|True | A600| 7|00:07:43
ip-172-32-5-239.eu-west-2.compute.internal:3000| A129|172.32.5.239:3000 |E-7.1.0.0| 0.000 | 3|155A640ADB8|True | A600| 7|00:09:38
Number of rows: 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Usage Information (2024-08-12 09:44:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Evictions| Stop|~System Memory~|~~~~Primary Index~~~~|~~Secondary~~~|~~~~~~~~~~~~~~~~~Storage Engine~~~~~~~~~~~~~~~~~
| | |Writes| Avail%| Evict%| Type| Used|Evict%|~~~~Index~~~~~| Type| Used|Used%|Evict%| Used|Avail%|Avail
| | | | | | | | | Type| Used| | | | | Stop%| |Stop%
mydata |172.32.15.231:3000 | 0.000 |False | 82| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.32.4.2:3000 | 0.000 |False | 82| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |ip-172-32-5-239.eu-west-2.compute.internal:3000| 0.000 |False | 81| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata | | 0.000 | | | | |0.000 B | | |0.000 B | |0.000 B |0.0 %| | | |
Number of rows: 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-12 09:44:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| |Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.15.231:3000 | 352| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.4.2:3000 | 600| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-5-239.eu-west-2.compute.internal:3000| 129| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 3
تبریک می گویم! شما باید هر شش گره را در خوشه کششی خود اضافه می کردید. این تنظیمات شامل سه گره ای است که شما در منطقه لندن پیکربندی کرده اید و سه گره در منطقه پاریس.
asadm -e i -Uadmin -Padmin
Seed: [('127.0.0.1', 3000, None)]
Config_file: /home/rocky/.aerospike/astools.conf, /etc/aerospike/astools.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information (2024-08-12 09:56:34 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node| IP| Build|Migrations|~~~~~~~~~~~~~~~Cluster~~~~~~~~~~~~~~~|Client| Uptime
| ID| | | |Size| Key|Integrity|Principal| Conns|
172.32.15.231:3000 | A352|172.32.15.231:3000|E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:20:06
172.32.4.2:3000 | A600|172.32.4.2:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:19:33
172.32.5.239:3000 | A129|172.32.5.239:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:21:28
172.33.11.90:3000 | A70|172.33.11.90:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 6|00:00:39
172.33.8.38:3000 |*A882|172.33.8.38:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:00:46
ip-172-33-7-44.eu-west-3.compute.internal:3000| A517|172.33.7.44:3000 |E-7.1.0.0| 0.000 | 6|ECACBC564992|True | A882| 7|00:00:39
Number of rows: 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Usage Information (2024-08-12 09:56:34 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Evictions| Stop|~System Memory~|~~~~Primary Index~~~~|~~Secondary~~~|~~~~~~~~~~~~~~~~~Storage Engine~~~~~~~~~~~~~~~~~
| | |Writes| Avail%| Evict%| Type| Used|Evict%|~~~~Index~~~~~| Type| Used|Used%|Evict%| Used|Avail%|Avail
| | | | | | | | | Type| Used| | | | | Stop%| |Stop%
mydata |172.32.15.231:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.32.4.2:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.32.5.239:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.33.11.90:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |172.33.8.38:3000 | 0.000 |False | 78| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 0.000 |False | 77| 50|shmem|0.000 B | 0.0 %|shmem|0.000 B |memory|0.000 B |0.0 %|60.0 %|70.0 %|99.0 %|5.0 %
mydata | | 0.000 | | | | |0.000 B | | |0.000 B | |0.000 B |0.0 %| | | |
Number of rows: 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-12 09:56:34 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| |Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.15.231:3000 | 352| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.4.2:3000 | 600| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 129| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.11.90:3000 | 70| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 882| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 517| 0| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
سازگاری قوی
برای فعال کردن قواعد Strong Consistency (SC) در Aerospike، باید چند دستور مدیریتی را اجرا کنید. این امر تقویت میکند که پایگاه داده شما یکپارچگی دقیق را در تمام گرههای خوشه حفظ میکند.
enable
manage roster stage observed ns mydata
manage recluster
برای بررسی اینکه گره ها بخشی از فهرست هستند، موارد زیر را اجرا کنید
show racks
~Racks (2024-08-12 10:00:00 UTC)~
Namespace|Rack|Nodes
| ID|
mydata | 70|A70
mydata | 129|A129
mydata | 352|A352
mydata | 517|A517
mydata | 600|A600
mydata | 882|A882
Number of rows: 6
show roster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 10:00:03 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
172.32.5.239:3000 |A129 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.15.231:3000 |A352 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
ip-172-33-7-44.eu-west-3.compute.internal:3000|A517 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.4.2:3000 |A600 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.11.90:3000 |A70 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.8.38:3000 |*A882|mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
Number of rows: 6
RACK-ID ها را ویرایش کنید
هر شش گره (سه گره در لندن و سه گره در پاریس) باید در خروجی ظاهر شوند، که نشان می دهد بخشی از فهرست خوشه فعلی هستند و به درستی پیکربندی شده اند.
اما صبر کن!
به نظر می رسد در حال حاضر شش قفسه در پیکربندی خوشه Aerospike شما نمایش داده شده است، که با تنظیم شما از 3 گره در هر منطقه و در مجموع 2 منطقه مطابقت ندارد. از آنجایی که تمام گرهها در هر ناحیه در یک زیرشبکه واحد هستند، میتوان آنها را در دو رک منطقی گروهبندی کرد.
برای تصحیح این، باید پیکربندی کلاستر را ویرایش کنید تا رکهای موجود را در تعداد مناسبی از rack-id (های) ادغام کنید. نمودار زیر را ببینید.
اقدام: خوشه را ویرایش کنید تا فقط 2 قفسه منطقی داشته باشیم.
# Login to the admin tool
asadm -Uadmin -Padmin
# show the roster
show roster
# Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 10:00:03 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
172.32.5.239:3000 |A129 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.15.231:3000 |A352 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
ip-172-33-7-44.eu-west-3.compute.internal:3000|A517 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.4.2:3000 |A600 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.11.90:3000 |A70 |mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.8.38:3000 |*A882|mydata |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70|A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
Number of rows: 6
# remove the n-1 nodes from the cluster
manage roster remove nodes A882@882 A600@600 A517@517 A352@352 A129@129 ns mydata
# check the current roster should only be a single node
show roster
# Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 11:25:26 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace|Current|Pending| Observed Nodes
| ID| | Roster| Roster|
ip-172-32-5-239.eu-west-2.compute.internal:3000|A129 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.15.231:3000 |A352 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.7.44:3000 |A517 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.32.4.2:3000 |A600 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.11.90:3000 |*A70 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
172.33.8.38:3000 |A882 |mydata |A70@70 |A70@70 |A882@882,A600@600,A517@517,A352@352,A129@129,A70@70
Number of rows: 6
# change the rack ids
manage config namespace mydata param rack-id to 32 with A129 A352 A600
manage recluster
info
manage config namespace mydata param rack-id to 33 with A70 A517 A882
manage recluster
info
manage roster stage observed A882@33,A600@32,A517@33,A352@32,A129@32,A70@33 ns mydata
manage recluster
show roster
# Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-12 11:31:08 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
ip-172-32-5-239.eu-west-2.compute.internal:3000|A129 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.32.15.231:3000 |A352 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.33.7.44:3000 |A517 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.32.4.2:3000 |A600 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.33.11.90:3000 |*A70 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
172.33.8.38:3000 |A882 |mydata |A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33|A882@33,A600@32,A517@33,A352@32,A129@32,A70@33
Number of rows: 6
show racks
# Output
~Racks (2024-08-12 11:31:34 UTC)~
Namespace|Rack| Nodes
| ID|
mydata | 32|A600,A352,A129
mydata | 33|A882,A517,A70
Number of rows: 2
تبریک می گویم! شما با موفقیت پیکربندی قفسه را برای خوشه Aerospike بین منطقه ای خود به روز کردید. این خوشه اکنون به دقت دو قفسه منطقی را منعکس می کند – یکی برای هر منطقه. فراموش نکنید که آن را تأیید و به روز کنید rack-id
مقادیر موجود در فایل پیکربندی Aerospike شما برای مطابقت با تنظیمات رک اصلاح شده. این اطمینان حاصل می کند که پیکربندی با معماری مورد نظر شما مطابقت دارد.
قسمت 3: درج چند رکورد
شما می خواهید تأیید کنید که داده ها در پایگاه داده Aerospike شما در حین انجام سناریوهای تقسیم مغز نوشته شده است. برای رسیدن به این هدف، یک برنامه پایتون پایه برای درج داده ایجاد خواهید کرد. این به شما کمک می کند تا رفتار خوشه و سازگاری داده ها را در شرایط آزمایش بررسی کنید. در زیر یک اسکریپت ساده پایتون وجود دارد که برخی از داده ها را در پایگاه داده Aerospike قرار می دهد. این اسکریپت از aerospike
کتابخانه مشتری برای اتصال به خوشه و انجام عملیات داده.
هنگامی که اسکریپت پایتون ارائه شده را برای درج داده ها در پایگاه داده Aerospike خود اجرا می کنید، داده ها باید به صورت زیر ساختار یافته و ذخیره شوند. در اینجا نمونه ای از نحوه ظاهر داده های درج شده آورده شده است:
یک هاست ec2 اضافی در یکی از زیرشبکه ها برای اجرای کد خود ایجاد کنید.
aql> select * from mydata.dummy limit 10
+------+------+--------------+------------------------+--------------------------------------------------------------------------------------------------------------------+
| PK | freq | country_code | logged_by | report |
+------+------+--------------+------------------------+--------------------------------------------------------------------------------------------------------------------+
| 134 | 340 | 199 | "FJ4Z50qm1YFKLC5g98T2" | MAP('{"colour-scheme":["purple", "magenta"], "date_mfg":"2024-02-09", "machine":["Surface"], "pixels":524288}') |
| 3758 | 408 | 121 | "rMyHrqM6eZcfYQCcCQFC" | MAP('{"colour-scheme":["cyan", "brown"], "date_mfg":"2023-10-07", "machine":["Inspiron"], "pixels":65536}') |
| 2297 | 323 | 81 | "kDeHYVgb4QqzCPj1RkOw" | MAP('{"colour-scheme":["orange", "green"], "date_mfg":"2021-08-18", "machine":["MacBook"], "pixels":16777216}') |
| 1841 | 833 | 224 | "2bedyAaZll3nPGKyty44" | MAP('{"colour-scheme":["green", "purple"], "date_mfg":"2022-07-02", "machine":["Chromebook"], "pixels":16777216}') |
| 3017 | 898 | 213 | "qwGXGe6BdbUHh8ZBGGit" | MAP('{"colour-scheme":["purple", "cyan"], "date_mfg":"2024-06-22", "machine":["ZenBook"], "pixels":32768}') |
| 3589 | 250 | 165 | "Od4R4ADltbWCD8budaco" | MAP('{"colour-scheme":["yellow", "green"], "date_mfg":"2018-08-02", "machine":["ThinkPad"], "pixels":65536}') |
| 2432 | 796 | 133 | "DD1Evor4WGFX9yr9WVuc" | MAP('{"colour-scheme":["brown", "cyan"], "date_mfg":"2022-02-04", "machine":["ThinkPad"], "pixels":4194304}') |
| 1652 | 623 | 1 | "HTkLNYHIPyYwUqtlZ883" | MAP('{"colour-scheme":["blue", "magenta"], "date_mfg":"2019-08-06", "machine":["Latitude"], "pixels":4096}') |
| 970 | 348 | 91 | "Cao8qtth9x981pjkpp9M" | MAP('{"colour-scheme":["red", "magenta"], "date_mfg":"2019-09-14", "machine":["Latitude"], "pixels":1048576}') |
| 2683 | 442 | 12 | "W9U9PBvCWodrTvf59FMz" | MAP('{"colour-scheme":["brown", "blue"], "date_mfg":"2024-01-14", "machine":["Latitude"], "pixels":2097152}') |
+------+------+--------------+------------------------+--------------------------------------------------------------------------------------------------------------------+
10 rows in set (0.033 secs)
برای کنترل مدت زمانی که برنامه پایتون شما باید اجرا شود و داده ها را در پایگاه داده Aerospike درج کند، دوره اجرای وقفه اسکریپت را تغییر دهید. این به شما امکان می دهد مدت زمان خاصی را برای اجرای اسکریپت تعیین کنید.
# Set a timeout value in seconds
run_for_sec = 30 # Adjust this value based on your needs
میزبان های بذر را برای خوشه Aerospike خود ویرایش کنید. من 1 گره از لندن و 1 گره از پاریس را انتخاب کرده ام.
hosts = [ ('172.33.7.44', 3000), ('172.32.5.239', 3000) ]
برای نصب موفقیت آمیز کتابخانه مشتری Aerospike Python، باید اطمینان حاصل کنید که وابستگی های خاصی برآورده شده است.
- python3-devel
- پایتون 3.8
- ساختن
به عنوان مثال از موارد زیر برای نصب استفاده کنید
sudo yum نصب python3-devel python3.8 make -y
سپس Aerospike Client Lib را با استفاده از pip نصب کنید.
sudo pip3.8 aerospike را نصب کنید
این هم کد:
import aerospike
from aerospike import exception as ex
import sys
import random
import string
from datetime import datetime, timedelta
import time
hosts = [ ('172.33.7.44', 3000), ('172.32.5.239', 3000) ]
run_for_sec = 60
# Sleep function to pause execution for a specified number of milliseconds
def sleep_ms(milliseconds):
time.sleep(milliseconds / 1000.0)
# Function to generate a list of random dates within a specified range
def generate_random_dates(num_dates):
start_date = datetime(2018, 1, 1) # Start date
end_date = datetime(2024, 8, 31) # End date
date_range = end_date - start_date # Calculate date range
random_dates = []
for _ in range(num_dates):
random_days = random.randint(0, date_range.days) # Generate random number of days
random_date = start_date + timedelta(days=random_days) # Add random days to start date
random_dates.append(random_date)
return random_dates
# Function to generate a random username of a given length
def generate_username(length):
characters = string.ascii_letters + string.digits # Pool of characters
username = ''.join(random.choice(characters) for _ in range(length))
return username
# Function to generate a list of random colors from a predefined set
def generate_random_colors(num_colors):
colors = ['red', 'blue', 'green', 'yellow', 'orange', 'purple', 'pink', 'brown', 'cyan', 'magenta']
random_colors = random.choices(colors, k=num_colors)
return random_colors
# Function to generate a list of random computer names from a predefined set
def generate_computer_names(num_computers):
computer_types = ['MacBook', 'ThinkPad', 'Chromebook', 'Surface', 'Latitude', 'Surface Book', 'Alienware', 'ZenBook', 'Inspiron', 'Pavilion']
names = random.sample(computer_types, num_computers)
return names
# Configuration for Aerospike client
config = {
'hosts': hosts, # Aerospike cluster hosts
'user': "admin",
'password': "admin"
}
namespace = 'mydata'
set = 'dummy'
try:
# Connect to Aerospike client
client = aerospike.client(config).connect()
print("Connected to Server")
# Create new write policy
write_policy = {'key': aerospike.POLICY_KEY_SEND}
# Set a timeout value in seconds
timeout = run_for_sec # Adjust this value based on your needs
# Define the start time
start_time = time.time()
count = 0
while True:
# Generate a random key
key = (namespace, set, random.randint(0, 4095))
# Generate random data for bins
number_sightings = random.randint(0, 1000)
cc = random.randint(0, 252)
user = generate_username(20)
date_made = generate_random_dates(1)
data = {
'machine': generate_computer_names(1),
'pixels': 2 ** random.randint(12, 24),
'colour-scheme': generate_random_colors(2),
'date_mfg': date_made[0].strftime("%Y-%m-%d")
}
# Create the bins
bins = {
'freq': number_sightings,
'country_code': cc,
'logged_by': user,
'report': data,
}
# Put the record into the Aerospike database
client.put(key, bins, policy=write_policy)
count = count + 1
# Check if the current time has exceeded the timeout
if time.time() - start_time > timeout:
print("Duration reached. Records[r/u]:",count)
break
# Sleep for 200 milliseconds
sleep_ms(200)
# Close the client connection
client.close()
except ex.ClientError as e:
# Handle client errors
print("Error: {0} [{1}]".format(e.msg, e.code))
sys.exit(1)
اطمینان حاصل کنید که برنامه پایتون شما برای مدت طولانی در پسزمینه اجرا میشود و به شما امکان میدهد آزمایشها و سناریوهای مختلف را شبیهسازی کنید.
python3.8 clientApp.py
قسمت 4: تقسیم مغز
در اینجا تصویری از سناریوی تقسیم مغز در یک سیستم داده توزیع شده ارائه شده است. این تصویر نشان می دهد که چگونه دو نیمه از یک سیستم داده (منطقه پاریس و منطقه لندن) ممکن است به دلیل جدایی شبکه از هم جدا شوند و به طور مستقل شروع به کار کنند. حتی ممکن است برخی فکر کنند که جالب است!
درک سازگاری قوی در Aerospike
در زمینه سیستم های پایگاه داده، ثبات قوی (SC) یک مفهوم حیاتی است، به ویژه در هنگام برخورد با سناریوهایی مانند شرایط تقسیم مغز. یک سناریوی تقسیم مغز زمانی اتفاق میافتد که یک پارتیشن شبکه، خوشه پایگاه داده را به دو یا چند پارتیشن تقسیم میکند که به طور بالقوه منجر به ناسازگاری دادهها میشود.
حالت سازگاری قوی Aerospike برای مقابله با چنین چالشهایی طراحی شده است و اطمینان حاصل میکند که همه نوشتهها در یک رکورد به ترتیب دقیق و متوالی اعمال میشوند. این تضمین میکند که هیچ نوشتهای مرتب یا نادیده گرفته میشود و در نتیجه هیچ دادهای از بین نمیرود.
در اینجا نگاهی عمیق تر به نحوه عملکرد قوام و اهمیت آن داریم:
ویژگی های کلیدی سازگاری قوی
-
متوالی می نویسد:
همه نوشتهها در یک رکورد به ترتیبی که دریافت میشوند اعمال میشوند. این تضمین می کند که وضعیت رکورد در تمام گره های خوشه قابل پیش بینی و سازگار است. -
بدون از دست دادن اطلاعات: حالت Aerospike SC تضمین می کند که داده ها از بین نمی روند، حتی در صورت خرابی پارتیشن های شبکه یا گره ها. با این حال، استثنائات نادری وجود دارد، مانند خرابی همزمان سخت افزار در گره های مختلف، که به طور بالقوه می تواند منجر به از دست رفتن داده ها شود.
-
تعهد بر اساس حد نصاب: نوشتن تنها زمانی موفق در نظر گرفته می شود که نصابی از گره ها عملیات نوشتن را تایید کنند. این بدان معنی است که اکثر گره ها باید در مورد نوشتن به توافق برسند و از ثبات داده ها حتی در صورت وجود خرابی گره ها یا مشکلات شبکه اطمینان حاصل کنند.
-
سازگاری فوری: به محض تایید یک عملیات نوشتن، تمام عملیات خواندن بعدی این نوشتن را منعکس می کنند. این در تضاد با ثبات نهایی است، جایی که خواندن ممکن است به طور موقت داده های قدیمی را بازگرداند.
ارزیابی سازگاری قوی در سناریوهای دوشاخه مغز
در طول یک سناریوی تقسیم مغز، پارتیشن شبکه می تواند به خوشه های جدا شده از گره ها منجر شود. ارزیابی رفتار Aerospike در چنین شرایطی برای درک استحکام حالت SC آن بسیار مهم است. در اینجا نحوه کمک به حالت SC آمده است:
-
عملیات را بنویسید: در یک سناریوی تقسیم مغز، نوشته ها فقط توسط گره هایی که یک پارتیشن اکثریت را تشکیل می دهند قابل پردازش هستند. این امر از نوشتن متناقض در یک رکورد از پارتیشن های مختلف جلوگیری می کند و یکپارچگی داده ها را حفظ می کند.
-
عملیات را بخوانید: Reads همیشه آخرین نوشتههایی را که توسط اکثر گرهها تایید شده است، برمیگرداند. اگر یک گره در یک پارتیشن اقلیت ایزوله شود، داده های قدیمی را به مشتریان ارائه نمی دهد.
-
آشتی پس از بهبودی: هنگامی که پارتیشن شبکه حل شد، Aerospike از حالت SC برای تطبیق هر حالت واگرا استفاده می کند. سیستم تضمین میکند که وضعیت رکوردها در تمام گرهها، بر اساس اکثر نوشتههایی که در طول پارتیشن انجام شدهاند، سازگار است.
نحوه ایجاد Split Brain
تصویر زیر نشان می دهد که شبکه کلی بین 2 منطقه و زیرشبکه های مربوط به آنها تقسیم شده است. در هر زیرشبکه، زیرخوشه اکنون دیدگاه خاص خود را از جهان دارد. هر زیرخوشه فقط با گره های داخل زیرشبکه خود ارتباط برقرار می کند.
برای شبیه سازی تقسیم شبکه بین مناطق در AWS، وارد کنسول AWS پاریس شوید. توجه داشته باشید که منبع روی تنظیم شده است 0.0.0.0/0
، به این معنی که اتصالات را می توان از هر جایی برقرار کرد.
این پیکربندی به ترافیک از هر آدرس IP اجازه دسترسی به این پورت ها را می دهد.
برای شبیه سازی تقسیم شبکه، باید ترافیک را محدود کنید تا فقط گره های درون یک زیرشبکه یا منطقه بتوانند با هم ارتباط برقرار کنند. به عنوان مثال، می توانید منبع را به بلوک CIDR خاص زیر شبکه خود تغییر دهید یا به خود گروه امنیتی ارجاع دهید. با اعمال این تغییرات، اطمینان حاصل کنید که:
- گره ها در منطقه پاریس می توانند با گره ها در هر دو منطقه پاریس و لندن ارتباط برقرار کنند.
- گره ها در منطقه لندن فقط می توانند با سایر گره های داخل منطقه لندن ارتباط برقرار کنند.
این پیکربندی به طور موثر یک تقسیم شبکه را شبیه سازی می کند که در آن زیر خوشه لندن از پاریس جدا شده است، در حالی که پاریس هنوز می تواند با هر دو منطقه تعامل داشته باشد.
با بررسی این جزئیات، مشخص می شود که تعداد رکوردها در لندن به دنبال جدایی شبکه به نصف کاهش یافته است.
قبل از رکوردهای 940 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 15:17:18 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.4.2:3000 | 32| 2| 0.000 |165.000 | 92.000 | 73.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |162.000 | 88.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.11.90:3000 | 33| 2| 0.000 |148.000 | 77.000 | 71.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.7.44:3000 | 33| 2| 0.000 |152.000 | 65.000 | 87.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |170.000 | 82.000 | 88.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |143.000 | 66.000 | 77.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |940.000 |470.000 |470.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
بعد از 470 رکورد 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 15:33:09 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.33.11.90:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.7.44:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.8.38:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.32.4.2:3000 | 32| 2| 0.000 |165.000 | 92.000 | 73.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |162.000 | 88.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |143.000 | 66.000 | 77.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |470.000 |246.000 |224.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
همانطور که می بینیم، گره های پاریس 🇫🇷 هیچ تغییری در تعداد رکوردها یا وضعیت آنها تجربه نکرده اند. این به این دلیل است که بنادر لندن هنوز به روی منابع باز هستند 0.0.0.0/0
، امکان ارتباط بین مناطق را فراهم می کند.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 15:53:59 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.15.231:3000 | 32| 2| 0.000 |143.000 | 66.000 | 77.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.4.2:3000 | 32| 2| 0.000 |165.000 | 92.000 | 73.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |162.000 | 88.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.11.90:3000 | 33| 2| 0.000 |148.000 | 77.000 | 71.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |170.000 | 82.000 | 88.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |152.000 | 65.000 | 87.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |940.000 |470.000 |470.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
Admin>
برنامه پایتون خود را از زیر شبکه ای در لندن اجرا کنید تا داده های ورودی بیشتری را از منطقه دیگری شبیه سازی کنید. به یاد بیاورید که داده های قبلی ما از پاریس ایجاد شده است.
قوانین ورودی گروه امنیتی لندن را تغییر دهید تا ترافیک فقط از زیرشبکه لندن مجاز باشد و تمام ترافیک خارجی از جمله ترافیک پاریس مسدود شود. با منزوی کردن لندن از پاریس، شما با موفقیت یک سناریوی کامل مغز را ایجاد کرده اید. این تنظیمات به درک اینکه چگونه پارتیشنهای شبکه بر توزیع داده و ارتباطات خوشهای در یک محیط پایگاه داده توزیع شده مانند Aerospike تأثیر میگذارند کمک میکند.
بیایید نتایج را ببینیم asadm
، ابزار مدیریت CLI Aerospike.
لندن 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:18:29 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.33.11.90:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.7.44:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.8.38:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.32.4.2:3000 | 32| 2| 0.000 |481.000 |155.000 |171.000 | 155.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |485.000 |178.000 |149.000 | 158.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |454.000 |147.000 |160.000 | 147.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.420 K|480.000 |480.000 | 460.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
پاریس 🇫🇷
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:18:16 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.15.231:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.4.2:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.5.239:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.11.90:3000 | 33| 2| 0.000 |471.000 |165.000 |156.000 | 150.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |463.000 |153.000 |154.000 | 156.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |466.000 |142.000 |150.000 | 174.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.400 K|460.000 |460.000 | 480.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
برنامه مشتری مستقر در لندن را اجرا کنید اکنون یک پارتیشن شبکه کامل داریم. توجه کنید که چگونه قبل از خراب شدن، چند رکورد برای پارتیشن هایی که دارد می نویسد.
python3.6 aerospike-client.py
Connected to Server
Error: Node not found for partition mydata:3773 [-8]
لندن 🏴
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:33:08 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.33.11.90:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.7.44:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.33.8.38:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.32.4.2:3000 | 32| 2| 0.000 |483.000 |156.000 |172.000 | 155.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |487.000 |179.000 |150.000 | 158.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-32-15-231.eu-west-2.compute.internal:3000| 32| 2| 0.000 |454.000 |147.000 |160.000 | 147.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.424 K|482.000 |482.000 | 460.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
پاریس 🇫🇷 – ما انتظار هیچ تغییری در تعداد رکورد نداریم زیرا نمی توانیم به پاریس برسیم
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:34:00 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.15.231:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.4.2:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.5.239:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.11.90:3000 | 33| 2| 0.000 |471.000 |165.000 |156.000 | 150.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |463.000 |153.000 |154.000 | 156.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |466.000 |142.000 |150.000 | 174.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.400 K|460.000 |460.000 | 480.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 6
به طور خلاصه، ما یک تقسیم یکنواخت از گره ها در هر زیرخوشه داریم و هر کدام آماده و در حال اجرا هستند اما فقط برای پارتیشن هایی که دارند.
مشاهدات کلیدی:
-
حتی اسپلیت: هر منطقه به طور مستقل عمل می کند و فقط پارتیشن هایی را که در اختیار دارد مدیریت می کند.
-
مالکیت پارتیشن: هر منطقه 50 درصد از کل پارتیشن ها را مدیریت می کند. این بدان معناست که پاریس نیمی از پارتیشن ها را اداره می کند و لندن نیمی دیگر را اداره می کند.
پاریس 🇫🇷
Admin> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-14 16:35:12 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
~~ |172.32.15.231:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.4.2:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.5.239:3000 | ~~| ~~| ~~| ~~| ~~
~~ | | | ~~| ~~| ~~| ~~
mydata |172.33.11.90:3000 |3CF08B51D327| 682| 700| 2048| 0
mydata |172.33.8.38:3000 |3CF08B51D327| 683| 669| 2048| 0
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000|3CF08B51D327| 683| 679| 2048| 0
mydata | | | 2048| 2048| 6144| 0
Number of rows: 6
-
توزیع پارتیشن:
show pmap
فرمان تأیید می کند که پارتیشن ها به طور مساوی بین مناطق پاریس و لندن تقسیم شده اند. گرههای هر منطقه سهم مساوی از پارتیشنها را مدیریت میکنند که با جداسازی شبکه که ما پیادهسازی کردهایم همسو است. -
عملیات خوشه: هر دو خوشه (پاریس و لندن) کاملاً عملیاتی هستند اما فقط برای پارتیشن هایی که در حال حاضر دارند. این نشان می دهد که چگونه مالکیت پارتیشن و توزیع داده حتی در طول یک تقسیم شبکه حفظ می شود.
با تجزیه و تحلیل این خروجی فرمان، واضح است که هر زیرخوشه در محدوده پارتیشن خود به درستی عمل می کند، که تأثیر پارتیشن شبکه بر مدیریت پارتیشن پایگاه داده Aerospike را نشان می دهد.
بازیابی پیکربندی پارتیشن شبکه
برای حل پارتیشن شبکه و بازیابی اتصال کامل، باید تغییرات قبلی قوانین گروه امنیتی ایجاد شده را لغو کنید و قوانین ورودی را دوباره تنظیم کنید تا ترافیک از همه منابع مجاز باشد (0.0.0.0/0
).
-
نقشه پارتیشن: پس از رفع محدودیت ها،
show pmap
دستور باید نشان دهد که تمام پارتیشن های 4096 به درستی در سراسر خوشه مدیریت می شوند، که نشان می دهد داده ها اکنون به طور کامل توزیع شده و در دسترس هستند. -
ارتباط گره: همه گره ها باید فعال باشند و با موفقیت با یکدیگر ضربان قلب کنند.
با دنبال کردن این مراحل، خوشه Aerospike را به حالت عملیاتی کامل آن بازیابی کردهاید، و مطمئن شوید که همه گرهها میتوانند با هم ارتباط برقرار کنند و توزیع دادهها در کل سیستم سازگار است.
Admin> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-14 16:46:53 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
mydata |172.32.15.231:3000 |4A4F30116D58| 683| 682| 0| 0
mydata |172.32.4.2:3000 |4A4F30116D58| 683| 683| 0| 0
mydata |172.32.5.239:3000 |4A4F30116D58| 682| 683| 0| 0
mydata |172.33.11.90:3000 |4A4F30116D58| 682| 683| 0| 0
mydata |172.33.8.38:3000 |4A4F30116D58| 683| 683| 0| 0
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000|4A4F30116D58| 683| 682| 0| 0
mydata | | | 4096| 4096| 0| 0
Number of rows: 6
Admin> i
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-14 16:46:58 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~Pending Migrates~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica| Tx| Rx
mydata |172.32.15.231:3000 | 32| 2| 0.000 |434.000 |147.000 |147.000 | 140.000 |0.000 |0.000 | 0.000 |431.000 |102.000
mydata |172.32.4.2:3000 | 32| 2| 0.000 |461.000 |156.000 |155.000 | 150.000 |0.000 |0.000 | 0.000 |423.000 |593.000
mydata |172.32.5.239:3000 | 32| 2| 0.000 |434.000 |179.000 |158.000 | 97.000 |0.000 |0.000 | 0.000 |425.000 |593.000
mydata |172.33.11.90:3000 | 33| 2| 0.000 |436.000 |165.000 |150.000 | 121.000 |0.000 |0.000 | 0.000 |440.000 |422.000
mydata |172.33.8.38:3000 | 33| 2| 0.000 |446.000 |153.000 |156.000 | 137.000 |0.000 |0.000 | 0.000 |426.000 |440.000
mydata |ip-172-33-7-44.eu-west-3.compute.internal:3000| 33| 2| 0.000 |446.000 |142.000 |174.000 | 130.000 |0.000 |0.000 | 0.000 |425.000 |418.000
mydata | | | | 0.000 | 2.657 K|942.000 |940.000 | 775.000 |0.000 |0.000 | 0.000 | 2.570 K| 2.568 K
Number of rows: 6
بخش 5: درک مدیریت پارتیشن در سازگاری قوی
با درک اینکه Aerospike چگونه پارتیشنها را تحت سازگاری قوی (SC) نگهداری میکند، توسعهدهندگان برنامهها و معماران راهحل میتوانند سیستمهای خود را برای مدیریت پارتیشنهای شبکه و حفظ یکپارچگی دادهها به طور موثر طراحی کنند. در اینجا نحوه استفاده از این دانش آمده است:
نکات کلیدی در مورد مدیریت پارتیشن Aerospike
-
ضمانتهای سازگاری قوی:
- حالت SC Aerospike تضمین میکند که همه نوشتهها در یک رکورد به ترتیب خاصی اعمال میشوند.
- این بدان معنی است که حتی در یک پارتیشن شبکه یا سناریوی تقسیم مغزی، تا زمانی که الزامات مالکیت پارتیشن و حد نصاب برآورده شود، سازگاری داده ها حفظ می شود.
-
مالکیت پارتیشن:
- هر گره در خوشه Aerospike بخشی از پارتیشن ها را مدیریت می کند. در طول یک تقسیم شبکه، گرهها در هر منطقه فقط پارتیشنهایی را که دارند مدیریت میکنند.
- این مالکیت پارتیشن کمک می کند تا اطمینان حاصل شود که داده ها به طور مداوم در هر زیر مجموعه پارتیشن مدیریت می شوند.
-
توزیع داده ها:
- در یک سیستم توزیع شده مانند Aerospike، داده ها به پارتیشن ها تقسیم می شوند و بین گره ها توزیع می شوند. در طول یک تقسیم، گره ها در هر منطقه به مدیریت و سرویس پارتیشن های خود ادامه می دهند. این رویکرد پارتیشن محور به حفظ تداوم عملیات حتی زمانی که بخش هایی از شبکه ایزوله هستند کمک می کند.
-
مدیریت پارتیشن های شبکه:
- هنگام طراحی سیستم ها با Aerospike، مهم است که احتمال پارتیشن های شبکه را در نظر بگیرید. درک اینکه چگونه پارتیشن ها مدیریت می شوند و چگونه سازگاری قوی حفظ می شود، امکان برنامه ریزی و استراتژی های کاهش بهتر را برای مدیریت چنین سناریوهایی فراهم می کند.
-
ملاحظات طراحی اپلیکیشن:
- افزونگی داده ها: بررسی کنید که داده ها در چندین گره تکثیر شوند تا در صورت خرابی گره یا منطقه از از دست رفتن داده ها جلوگیری شود.
- پیکربندی حد نصاب: تنظیمات حد نصاب را برای تعادل بین عملکرد و سازگاری داده ها، با در نظر گرفتن پتانسیل پارتیشن های شبکه، پیکربندی کنید.
- نظارت و هشدار: اجرای مکانیزم های نظارت و هشدار قوی برای شناسایی و پاسخگویی سریع به پارتیشن های شبکه و سناریوهای تقسیم مغز.
-
معماری راه حل:
- معماری را طوری طراحی کنید که تاثیر پارتیشن های شبکه را به حداقل برساند.
- این شامل پیکربندی شبکه و تنظیمات امنیتی برای کنترل دسترسی بین مناطق و حصول اطمینان از اینکه سیستم میتواند پارتیشنها را به خوبی و بدون تناقض دادههای قابل توجه اداره کند.
با گنجاندن این ملاحظات در طراحی برنامه و معماری راه حل خود، می توانید از ویژگی های سازگاری قوی Aerospike برای ایجاد سیستم های مقاوم و مقاوم در برابر خطا استفاده کنید که یکپارچگی داده ها را حتی در شرایط پیچیده شبکه حفظ می کند.
بالاخره: بعدش چی؟
بررسی سناریوهای مختلف پارتیشن شبکه
در این مقاله، بررسی کردیم که چگونه یک تقسیم شبکه (تقسیم مغز) می تواند بر سیستم داده های توزیع شده تأثیر بگذارد. ما در ابتدا بر تقسیم مساوی در دو منطقه تمرکز کردیم، اما جایگشت های متعددی از پارتیشن های شبکه وجود دارد که می تواند نتایج جالب و متنوعی را به همراه داشته باشد.
در اینجا به چند مورد از این سناریوها می پردازیم.
الف: تقسیم ناهموار زیرشبکه در یک منطقه
-
پیکربندی:
- منطقه لندن: 6 گره (2 گره در هر 3 زیرشبکه)
- منطقه پاریس: 6 گره (2 گره در هر 3 زیرشبکه)
-
پارتیشن شبکه:
- پارتیشن به یک زیرشبکه واحد در منطقه لندن بومی سازی شده است.
-
نتیجه مورد انتظار:
- زیرشبکه اکثریت با پارتیشن شبکه به طور مستقل عمل می کند، که منجر به تقسیم ناهموار در منطقه می شود و به احتمال زیاد همه پارتیشن های پایگاه داده فعال را خواهد داشت.
- با ضریب تکرار > 1 و یک چیدمان رک منطقی به درستی پیکربندی شده، همه پارتیشن های پایگاه داده در زیرشاخه 5 زیرشبکه در دسترس خواهند بود.
- گرهها در زیرشبکه منفرد به عملکرد عادی خود ادامه میدهند، اما ممکن است هیچ پارتیشن پایگاه داده فعال نداشته باشند.
ب: تقسیم ناهموار در مناطق – 2 قفسه در هر منطقه
هر منطقه شامل 2 رک است که برای سازگاری قوی با ضریب تکرار 3 پیکربندی شده اند. این ضریب تکرار تضمین می کند که یک کپی از داده ها همیشه در مرکز داده جایگزین نوشته می شود. داشتن بیش از 1 رک امکان انعطاف پذیری در برابر خرابی مرکز داده یا رک را می دهد که سناریوی واقعی تری است.
-
پیکربندی:
- منطقه لندن: 4 گره (2 قفسه)
- منطقه پاریس: 3 گره (2 قفسه)
-
پارتیشن شبکه:
- بین دو منطقه تقسیم شود.
-
نتیجه مورد انتظار:
- داده ها در خوشه اقلیت پاریس در حالت استراحت خواهند بود اما در دسترس نیستند
- با ضریب تکرار 3 یا بیشتر و سازگاری قوی، بازنشانی فهرست به صورت دستی به گرههای موجود، سیستم را بدون از دست دادن داده به حالت آنلاین باز میگرداند.
در شرایط عادی، هنگام نوشتن یک رکورد با ضریب تکرار 3 (rf:3)، نوشتن اصلی و کپی ها می توانند در هر یک از 4 قفسه توزیع شوند. از آنجایی که هر منطقه فقط 2 قفسه دارد، حداقل یک کپی تضمین شده است که در یک رک متفاوت در منطقه دیگر نوشته شود.
ترکیب های احتمالی را در زیر مشاهده کنید:
[100,101,102] [100,101,103] [100,102,103] [101,102,103]
برای آنلاین کردن خوشه اقلیت، باید 3 گره در پاریس را دوباره اختصاص دهید.
پس از فهرستبندی مجدد دستی به گرههای باقیمانده جدید، اکنون خوشه مانند زیر عملیاتی میشود.
سی: تقسیم ناهموار در مناطق
رویداد فاجعه بار که در آن اکثر 4 گره منطقه لندن به طور دائم آفلاین می شوند. حالت خوشه چگونه به نظر می رسد و اتصال مشتری چگونه تحت تأثیر قرار می گیرد؟
-
پیکربندی:
- منطقه لندن: 4 گره
- منطقه پاریس: 3 گره
-
پارتیشن شبکه:
- بین دو منطقه تقسیم شود.
-
نتیجه مورد انتظار:
- داده ها در خوشه اقلیت پاریس باقی می مانند اما در دسترس نیستند.
- با ضریب تکرار 2 یا بیشتر و سازگاری قوی، تنظیم مجدد فهرست به صورت دستی به گره های موجود، سیستم را بدون از دست دادن داده بازیابی می کند.
ما تمرکز دقیقی روی این سناریوی خاص خواهیم داشت زیرا چالشی جذاب را ارائه می دهد.
در حال حاضر، شما باید با راه اندازی VPC ها در دو منطقه و ایجاد یک ارتباط همتا بین آنها آشنا باشید. اگر به تجدید نظر نیاز دارید، به قسمت 1 مجموعه با عنوان “برنامه پیام رسانی ساده بین منطقه ای” مراجعه کنید.
در مرحله بعد، 4 نمونه EC2 در هر منطقه ایجاد کنید، اما Aerospike را فقط روی 7 گره نصب کنید. این یک خوشه با اندازه عجیب را تضمین می کند که برای این آزمایش بسیار مهم است. اگر در این مرحله به راهنمایی نیاز دارید، از قسمت 2 – “نصب Aerospike NoSQL DB as a Stretch Cluster” دیدن کنید. هر آنچه را که نیاز دارید در آنجا پیدا خواهید کرد.
پس از تکمیل، باید سازگاری قوی را با 2 قفسه به شماره 32 و 33 فعال کنید.
اکنون زمان درج برخی از داده های آزمایشی است. ما این را در قسمت 3 پوشش دادیم، بنابراین با خیال راحت از همان کد استفاده مجدد کنید و فقط آدرسهای میزبان اولیه را بهروزرسانی کنید.
قبل از افزودن هر گونه داده، وضعیت فعلی خوشه را بررسی کنید. در این مرحله نباید هیچ داده ای وجود داشته باشد.
# 4:3 split over 2 racks '32' and '33'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:18:31 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| |Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |0.000 |0.000 |0.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |
با استفاده از برنامه پایتون، چند رکورد تست را وارد کنید
python3.8 app.py
Connected to Server
Timeout reached. Exiting loop.
برای اولین اجرا ما 271 رکورد در تمام گره ها و مناطق تقسیم شده بود. جالب است اگر رکوردهای اصلی را در رک '32' خلاصه کنید [ 35+40+33+38=146] این باید با رکوردهای prole در رک '33' برابری کند [52+53+41=146].
این به این دلیل است که ما 2 رک با ضریب تکرار 2 داریم. ما انتظار داریم که در شرایط عادی یک نوشتن در rack rx با یک کپی در rack ry نوشته شود و در سازگاری قوی ما هیچ ابهامی در مورد نوشته شدن یا ننوشتن یک رکورد را تضمین نمی کنیم. .( توجه: با ضریب تکرار 2 و یک رک منفرد با 2 یا بیشتر گره موجود است، مشتریان همچنان می توانند داده ها را با موفقیت بنویسند)
# 271 master records
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:21:31 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 | 71.000 | 35.000 | 36.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 | 71.000 | 40.000 | 31.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 | 60.000 | 33.000 | 27.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 | 69.000 | 38.000 | 31.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 | 98.000 | 46.000 | 52.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 | 88.000 | 35.000 | 53.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 | 85.000 | 44.000 | 41.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |542.000 |271.000 |271.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
ادامه دهید و داده های بیشتری را وارد کنید و شاید بررسی های حسابداری مانند بالا را امتحان کنید.
python3.8 app.py
Connected to Server
Timeout reached. Exiting loop.
# 517 master records
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:24:13 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 |134.000 | 68.000 | 66.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 |137.000 | 78.000 | 59.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 |110.000 | 63.000 | 47.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 |136.000 | 77.000 | 59.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 |192.000 | 79.000 |113.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |160.000 | 67.000 | 93.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |165.000 | 85.000 | 80.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.034 K|517.000 |517.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
در رک 32 چند رکورد مستر و در رک 33 چند رکورد پرول به دست آوردید؟
بن بنگ! ادامه دهید و هر 4 گره را در منطقه لندن خاموش کنید. شما asadm
دستورات info و pmap باید شبیه زیر باشد:
Admin+> info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:26:44 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~Objects~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 | 33| 2| 0.000 |192.000 |0.000 |0.000 | 192.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |160.000 |0.000 |0.000 | 160.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |165.000 |0.000 |0.000 | 165.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 |517.000 |0.000 |0.000 | 517.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
Admin+> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-21 12:28:14 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~
~~ | | | ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 |39A2BCE70658| 0| 0| 4096| 0
mydata |172.33.46.58:3000 |39A2BCE70658| 0| 0| 4096| 0
mydata |ip-172-33-42-240.eu-west-3.compute.internal:3000|39A2BCE70658| 0| 0| 4096| 0
mydata | | | 0| 0| 12288| 0
در این مرحله کلاینت شما نمی تواند به هیچ پارتیشنی دسترسی داشته باشد. برای حل این مشکل، پس از اطمینان از پایداری سیستم، باید یک فرمان اپراتور صادر کنید. در اصل، تمام گرههای رک '32' را از فهرست حذف کنید.
Admin+> manage roster remove nodes A541@32 A445@32 A333@32 A332@32 ns mydata
Node(s) successfully removed from pending-roster.
Run "manage recluster" for your changes to take affect.
Admin+> manage recluster
Successfully started recluster
Admin+> show roster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-21 12:29:03 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node ID|Namespace| Current Roster| Pending Roster| Observed Nodes
172.32.1.105:3000 |000000000000000|~~ |~~ |~~ |~~
172.32.8.190:3000 |000000000000000|~~ |~~ |~~ |~~
172.32.7.25:3000 |000000000000000|~~ |~~ |~~ |~~
172.32.0.79:3000 |000000000000000|~~ |~~ |~~ |~~
172.33.46.58:3000 |A250 |mydata |A829@33,A476@33,A250@33|A829@33,A476@33,A250@33|A829@33,A476@33,A250@33
ip-172-33-42-240.eu-west-3.compute.internal:3000|A476 |mydata |A829@33,A476@33,A250@33|A829@33,A476@33,A250@33|A829@33,A476@33,A250@33
172.33.35.102:3000 |*A829 |mydata |A829@33,A476@33,A250@33|A829@33,A476@33,A250@33|A829@33,A476@33,A250@33
Number of rows: 7
Admin+> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-21 12:29:11 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~
~~ | | | ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 |E6BE8E200C70| 1366| 1365| 0| 0
mydata |172.33.46.58:3000 |E6BE8E200C70| 1365| 1365| 0| 0
mydata |ip-172-33-42-240.eu-west-3.compute.internal:3000|E6BE8E200C70| 1365| 1366| 0| 0
mydata | | | 4096| 4096| 0| 0
Number of rows: 7
در این مرحله مشتری شما باید قادر به نوشتن داده باشد. با این حال، بیایید تعداد کل رکوردها را تأیید کنیم.
# After recluster we have 517 records as before
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:29:31 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 | 33| 2| 0.000 |364.000 |195.000 |169.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |331.000 |158.000 |173.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |339.000 |164.000 |175.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.034 K|517.000 |517.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
قبل از احیای قفسه '32' در لندن، داده های آزمایشی اضافی را وارد کنید.
python3.8 app.py
Connected to Server
Timeout reached. Exiting loop.
# We now have 778 records
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:44:51 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
~~ |172.32.0.79:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.1.105:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.7.25:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ |172.32.8.190:3000 | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
~~ | | | | ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~| ~~
mydata |172.33.35.102:3000 | 33| 2| 0.000 |557.000 |295.000 |262.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |498.000 |250.000 |248.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |501.000 |233.000 |268.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.556 K|778.000 |778.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
اکنون به طور قابل اعتمادی به شما اطلاع داده شده است که قطعی قطع شده است، همه گرههای رک '32' را دوباره آنلاین کنید.
Admin+> manage roster stage observed A541@32,A445@32,A333@32,A332@32 ns mydata
Pending roster now contains observed nodes.
Run "manage recluster" for your changes to take affect.
Admin+> manage recluster
Successfully started recluster
Admin+> show racks
~Racks (2024-08-21 12:48:07 UTC)~~
Namespace|Rack| Nodes
| ID|
mydata | 32|A541,A445,A333,A332
mydata | 33|A829,A476,A250
Number of rows: 2
Admin+> show pmap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Partition Map Analysis (2024-08-21 12:48:13 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node| Cluster Key|~~~~~~~~~~~~Partitions~~~~~~~~~~~~
| | |Primary|Secondary|Unavailable|Dead
mydata |172.32.0.79:3000 |4AC63FB091A3| 109| 915| 0| 0
mydata |172.32.1.105:3000 |4AC63FB091A3| 103| 921| 0| 0
mydata |172.32.7.25:3000 |4AC63FB091A3| 111| 913| 0| 0
mydata |172.32.8.190:3000 |4AC63FB091A3| 99| 925| 0| 0
mydata |172.33.35.102:3000 |4AC63FB091A3| 1213| 179| 0| 0
mydata |172.33.46.58:3000 |4AC63FB091A3| 1226| 185| 0| 0
mydata |ip-172-33-42-240.eu-west-3.compute.internal:3000|4AC63FB091A3| 1235| 167| 0| 0
mydata | | | 4096| 4205| 0| 0
Number of rows: 7
Admin+> show roster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Roster (2024-08-21 12:48:19 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node| Node|Namespace| Current Roster| Pending Roster| Observed Nodes
| ID| | | |
172.33.46.58:3000 |A250 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.8.190:3000 |A332 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.1.105:3000 |A333 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.7.25:3000 |A445 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
ip-172-33-42-240.eu-west-3.compute.internal:3000|A476 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.32.0.79:3000 |A541 |mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
172.33.35.102:3000 |*A829|mydata |A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33|A829@33,A541@32,A476@33,A445@32,A333@32,A332@32,A250@33
Number of rows: 7
# 778 records
Admin+> info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Object Information (2024-08-21 12:49:17 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace| Node|Rack| Repl|Expirations| Total|~~~~~~~~~~~~Objects~~~~~~~~~~~~|~~~~~~~~~Tombstones~~~~~~~~|~~~~Pending~~~~
| | ID|Factor| | Records| Master| Prole|Non-Replica| Master| Prole|Non-Replica|~~~~Migrates~~~
| | | | | | | | | | | | Tx| Rx
mydata |172.32.0.79:3000 | 32| 2| 0.000 |195.000 |100.000 | 95.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.1.105:3000 | 32| 2| 0.000 |209.000 |115.000 | 94.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.7.25:3000 | 32| 2| 0.000 |176.000 |102.000 | 74.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.32.8.190:3000 | 32| 2| 0.000 |198.000 |108.000 | 90.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.35.102:3000 | 33| 2| 0.000 |291.000 |126.000 |165.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |172.33.42.240:3000 | 33| 2| 0.000 |252.000 |104.000 |148.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata |ip-172-33-46-58.eu-west-3.compute.internal:3000| 33| 2| 0.000 |235.000 |123.000 |112.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
mydata | | | | 0.000 | 1.556 K|778.000 |778.000 | 0.000 |0.000 |0.000 | 0.000 |0.000 |0.000
Number of rows: 7
وویلا! – به نظرم خوبه ما همه 778 رکوردی که انتظار داشتیم را داریم.
خودکار کردن سناریوهای پارتیشن شبکه
خودکارسازی این سناریوها می تواند در زمان صرفه جویی کرده و احتمال خطای انسانی را کاهش دهد. می توانید از اسکریپت ها و ابزارهایی مانند AWS CLI یا Terraform برای ایجاد و مدیریت این پارتیشن های شبکه استفاده کنید.
آینده: Service Mesh و Kubernetes
در مقاله بعدی، ایجاد یک سناریوی پارتیشن شبکه مشابه با استفاده از مش سرویس و گسترش یک کلاستر پایگاه داده در Kubernetes با اپراتور Aerospike Kubernetes را بررسی خواهیم کرد.
تماس و بازخورد
اگر سؤال یا پیشنهادی دارید، میتوانید به آدرس icloud.nkm@gmail.com به من مراجعه کنید.
نتیجه گیری
ما در مورد سناریوهای مختلف پارتیشن شبکه و تأثیرات بالقوه آنها بر یک سیستم داده توزیع شده بحث کرده ایم. با درک و آزمایش این سناریوها، می توانید سیستم های انعطاف پذیرتر و قوی تری طراحی کنید.
امیدوارم از خواندن این مقاله لذت برده باشید و چیزهای جدیدی یاد گرفته باشید.