მიგრაციის ტესტირება EVE-NG-ში პროდაქშენზე შეხებამდე (ქსელის ციფრული ასლი)

ცვლილებების ფანჯარა მოკლეა, და მასში შეცდომის აღმოჩენის ფასი იზომება ავარიის ხანგრძლივობითა და rollback-ის ხანგრძლივობით. ციფრული ასლი ამ აღმოჩენას გადააქვს იქ, სადაც შეცდომა უფასოა: ლაბორატორიაში, სადაც მუშაობს იგივე პროგრამული ვერსია, იგივე კონფიგურაცია და იგივე ტოპოლოგია, და სადაც ყველაფრის შეგნებულად და მრავალჯერ გაფუჭება შეიძლება.

ქსელურ სამყაროში ამისთვის ჩვეულებრივ EVE-NG გამოიყენება. ის სიმულატორი არ არის — ის ვენდორების რეალურ image-ებს უშვებს KVM-ზე — და სწორედ ამიტომ გადმოაქვს შედეგები რეალობაში, და სწორედ აქვეა მისი ზღვრებიც.

რისთვისაა ასლი და რისთვის არა#

ლაბორატორია ერთგულად იმეორებს control plane-ს: მარშრუტიზაციის პროტოკოლების ქცევას, პოლიტიკის შეფასებას, კონვერგენციის თანმიმდევრობას, კონფიგურაციის სინტაქსს, მიგრაციის ბრძანებების ზუსტ რიგს. ეს ფარავს იმის უმეტესობას, რაც ცვლილებისას ფუჭდება.

ის არ იმეორებს forwarding plane-ს. არ არის ASIC, არ არის აპარატურული რიგები, არ არის რეალური line-rate ქცევა, არ არის ვენდორის control-plane policing, არ არის ოპტიკა. თუ თქვენი კითხვაა „აირჩევს თუ არა ეს პოლიტიკა სწორ გზას“ — ლაბორატორია პასუხობს. თუ კითხვაა „გაატარებს თუ არა ეს პლატფორმა 40 Gbit/s მცირე პაკეტებს ამ ფუნქციით ჩართული“ — ვერ პასუხობს, და საპირისპიროს მოჩვენება უარესია, ვიდრე საერთოდ არტესტირება.

გადაწყვიტეთ, რომელ კითხვას სვამთ, სანამ რამეს ააწყობთ.

ჰოსტის რესურსების გათვლა#

ვირტუალური როუტერები მეხსიერებაზე მადიანია და CPU-ზე — ზომიერად. ყველაფერზე ადრე დარწმუნდით, რომ ჰოსტს ჩადგმული ვირტუალიზაცია აქვს, რადგან KVM სტუმარი, რომელიც ემულაციაზე გადადის, გამოუსადეგარად ნელია:

# აქვს თუ არა CPU-ს აპარატურული ვირტუალიზაცია?
grep -cE '(vmx|svm)' /proc/cpuinfo

# ჩართულია თუ არა nested ვირტუალიზაცია? (Intel; AMD-ზე kvm_amd)
cat /sys/module/kvm_intel/parameters/nested

# ჩატვირთულია თუ არა KVM მოდულები
lsmod | grep -E '^kvm'

თუ თავად EVE-NG ჰიპერვიზორის შიგნით მუშაობს, nested ვირტუალიზაცია გარე ფენაზეც უნდა იყოს ჩართული, ხოლო სტუმრის CPU გადაცემული და არა ემულირებული.

რესურსები დაითვალეთ თითო კვანძზე ვენდორის მინიმუმიდან იმ image-ისთვის, რომელსაც იყენებთ, და არა საშუალოდან. სრულფუნქციური ვირტუალური როუტერი ითხოვს რამდენიმე vCPU-ს და რამდენიმე გიგაბაიტ ოპერატიულს; კონტეინერული მარშრუტიზაციის დემონი — ამის მცირე ნაწილს. აქედან პრაქტიკული საპროექტო არჩევანი: ტოპოლოგიის ის ნაწილი, რომელსაც ტესტავთ, ააწყვეთ ვენდორის რეალური image-ებით, ხოლო გარშემო არსებული „ინტერნეტი“ ან კამპუსი — მსუბუქი კვანძებით. ოცი FRR კონტეინერი, რომელიც მარშრუტებს აანონსებს, სავსებით კარგი „დანარჩენი მსოფლიოა“ BGP პოლიტიკის ტესტისთვის.

Image-ების შემოტანა და სწორი სახელები#

EVE-NG სახელდებაზე მკაცრია — პლატფორმის template დირექტორიის სახელიდან გამოიყვანება, და არასწორი სახელი იძლევა კვანძს, რომელიც არ ჩაიტვირთება და გასაგებ შეცდომას არ გამოიტანს.

# qcow2 image-ები თითო image-ის დირექტორიაშია
mkdir -p /opt/unetlab/addons/qemu/vmx-14.1R4/
# დისკი გადაწერეთ იმ ფაილის სახელით, რომელსაც template ელოდება, შემდეგ:
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

ორი პრაქტიკული შენიშვნა. ლიცენზირება თქვენი პასუხისმგებლობაა: ვენდორის image-ები, როგორც წესი, უფლებას მოითხოვს, ხოლო ზოგიერთი ვირტუალური პლატფორმის უფასო დონე გამტარუნარიანობას ისეთ ზღვარზე ჭრის, რომელიც control-plane სამუშაოსთვის საკმარისია და სხვა ყველაფრისთვის — უსარგებლო. ეს დასაშვებია, რადგან ლაბორატორია სწორედ control-plane სამუშაოსთვისაა. და გქონდეთ image-ების ინვენტარი პროდაქშენში მომუშავე ზუსტი ვერსიებით. მიგრაციის ტესტირება იმისგან განსხვავებულ რელიზზე, რომელიც დანერგილია, იძლევა ნდობას, რომელიც არსად გადადის.

პროდაქშენის კონფიგურაციის პატიოსნად შემოტანა#

ცდუნებაა, ხელით დაწეროთ „რეპრეზენტატული“ კონფიგურაცია. ნუ დაწერთ — შეცდომები სწორედ იმ ნაწილებში ცხოვრობს, რომელთა ხელით დაწერაც არავის მოუვიდოდა აზრად.

წამოიღეთ რეალური მოქმედი კონფიგურაცია და შემდეგ ზუსტად სამი კატეგორია შეცვალეთ:

1. საიდუმლოებები. წაშალეთ ან ჩაანაცვლეთ ყველა credential, SNMP community, BGP MD5 გასაღები, RADIUS secret და სერტიფიკატი. ლაბორატორია დაცული გარემო არ არის და მისი სნეპშოტები დადის ხელიდან ხელში.
2. ინტერფეისების სახელები. ვირტუალური პლატფორმები იშვიათად იმეორებენ აპარატურის სახელდებას. ge-0/0/0 მიაბით იმას, რასაც image რეალურად გთავაზობთ, და შესაბამისობის ცხრილი ლაბორატორიასთან ერთად შეინახეთ — მომავალ თქვენ ის დაგჭირდებათ diff-ების წასაკითხად.
3. მართვა და out-of-band. გადაწერეთ მართვის VRF, NTP-სა და syslog-ის მისამართები და ყველაფერი, რაც ლაბორატორიულ კვანძს პროდაქშენის სისტემებთან ალაპარაკებდა. სწორედ ეს კბენს: ლაბორატორიული როუტერი, რომელიც წარმატებით წვდება პროდაქშენის RADIUS სერვერს ან, უარესი, რეალურ BGP სესიას აყალიბებს, ლაბორატორია აღარ არის.

დანარჩენი — პოლიტიკები, prefix-list-ები, route-map-ები, community-ები, IGP მეტრიკები — გადმოდის სიტყვასიტყვით. სწორედ ეს არის აზრი.

ლაბორატორიის დაკავშირება გარესამყაროსთან#

ჩვეულებრივ ორი ტიპის გარე კავშირი გჭირდებათ: მართვის წვდომა ავტომატიზაციისთვის და ტრაფიკის წყაროები ვალიდაციისთვის. EVE-NG ორივესთვის ხიდურ Cloud ინტერფეისებს გთავაზობთ. მართვა დასვით ერთ ხიდზე, ტრაფიკის გენერატორები — მეორეზე, რომ სატესტო ნაკადმა თქვენივე წვდომა ლაბორატორიაზე ვერ შეაფერხოს.

ტრაფიკისთვის მცირე Linux კვანძები საკმარისია იმ კითხვებისთვის, რომლებზეც control-plane ლაბორატორია პასუხობს:

# path MTU-ს ქცევა: 1472 payload + 28 ბაიტი სათაური = 1500
ping -M do -s 1472 10.20.30.1

# გამტარუნარიანობა და დანაკარგი ორ ლაბორატორიულ ჰოსტს შორის
iperf3 -c 10.20.30.1 -u -b 100M -t 30

# ჭრის თუ არა პოლიტიკა ნამდვილად იმას, რაც უნდა დაიჭრას?
hping3 -S -p 443 -c 5 10.20.30.1

სატესტო გეგმა ცვლილებამდე#

ლაბორატორია სასარგებლოა მხოლოდ მაშინ, თუ იცით, როგორ გამოიყურება „სწორი“. დააფიქსირეთ მდგომარეობა მანამდე, გაატარეთ ცვლილება, დააფიქსირეთ მდგომარეობა შემდეგ და შეადარეთ. გააკეთეთ სკრიპტით და არა თვალით — ადამიანი, რომელიც ორ 400-სტრიქონიან BGP summary-ს ადარებს, სტაბილურად უშვებს იმ ერთ სტრიქონს, რომელსაც მნიშვნელობა აქვს.

# ერთი და იმავე ბრძანებების ნაკრების ფიქსაცია ცვლილებამდე და შემდეგ
import re

from netmiko import ConnectHandler

COMMANDS = [
    "show bgp summary",
    "show route summary",
    "show interfaces terse",
    "show configuration | display set",
]

def snapshot(host, tag):
    conn = ConnectHandler(device_type="juniper_junos", host=host,
                          username="lab", password="lab")
    for cmd in COMMANDS:
        out = conn.send_command(cmd)
        slug = re.sub(r"[^a-z0-9]+", "_", cmd.lower()).strip("_")
        with open(f"{tag}-{host}-{slug}.txt", "w") as fh:
            fh.write(out)
    conn.disconnect()

შემდეგ შეადარეთ ისინი წყვილ-წყვილად და შედეგის ყოველი სტრიქონი წაიკითხეთ:

for f in before-*.txt; do diff -u "$f" "after-${f#before-}"; done

სასარგებლო ინვარიანტები, რომლებიც ცალსახად უნდა შეამოწმოთ:

• მეზობლების რაოდენობა და სესიების მდგომარეობა თითო მოწყობილობაზე, მანამდე და შემდეგ.
• მიღებული და გაცემული პრეფიქსების რაოდენობა თითო სესიაზე — მკვეთრი კლება ფილტრის შეცდომაა, მკვეთრი ზრდა — leak.
• სრული ping და traceroute მატრიცა იმ საზღვრებს შორის, რომლებიც გაინტერესებთ.
• მარშრუტების რაოდენობა თითო პროტოკოლზე, რომ გადანაწილების შეცდომა ციფრად გამოჩნდეს და არა კლიენტის საჩივრად.

შექმენით სწორედ ის ავარიები, რომლებისაც გეშინიათ#

მიგრაცია, რომელიც მხოლოდ იდეალურ სცენარზე მუშაობს, გატესტილი არ არის. ლაბორატორიაში გაფუჭება არაფერი ჯდება:

• ცვლილების შუაში ჩამოაგდეთ არხი და შეამოწმეთ ტრაფიკის გზა და რეკონვერგენციის დრო.
• კვანძი მკვეთრად მოკალით (და არა graceful shutdown-ით) და ნახეთ, რას იზამენ მეზობლები თავიანთი ტაიმერებით.
• გაითამაშეთ route leak „კლიენტი“ კვანძიდან, რომელიც სრულ ცხრილს აანონსებს, და დარწმუნდით, რომ maximum-prefix ისე მუშაობს, როგორც დააკონფიგურირეთ.
• შეიტანეთ MTU-ს შეუსაბამობა ერთ მონაკვეთზე და დააკვირდით, რომელი პროტოკოლი გადარჩება და რომელი უხმაუროდ — არა.
• გააკეთეთ rollback შუა გზიდან, ნახევრად გატარებული მდგომარეობიდან — ეს ის სცენარია, რომლის რეპეტიციასაც არავინ ატარებს და რომელსაც ადრე თუ გვიან ყველა ხვდება.

რეპეტიცია, შემდეგ runbook#

ბოლო გავლა სრული გენერალური რეპეტიციაა: მიგრაცია გაატარეთ ზუსტად ისე, როგორც პროდაქშენში გაატარებთ, იმავე სკრიპტიდან ან ბრძანებების იმავე სიიდან, თითო ნაბიჯის დროის გაზომვით. სწორედ აქედან გამოსული შედეგია მიწოდებადი პროდუქტი:

• ბრძანებების ზუსტი თანმიმდევრობა, რიგის დაცვით, თითოს შემდეგ მოსალოდნელი გამონატანით.
• დრო თითო ნაბიჯზე, რომ ცვლილებების ფანჯარა გაზომვიდან დაიგეგმოს და არა ოპტიმიზმიდან.
• rollback-ის თანმიმდევრობა, გატესტილი იმავე ნახევრად გატარებული მდგომარეობიდან, რომელიც ზემოთ გაიმეორეთ.
• შემოწმების ბრძანებები და მათი სწორი გამონატანის აღწერა — რომ ღამის სამ საათზე მორიგე ინჟინერს კონკრეტული საყრდენი ჰქონდეს.

ლაბორატორია მიგრაციის შემდეგაც შეინახეთ#

ტიპური ფლანგვაა ტოპოლოგიის წაშლა მაშინ, როცა მიგრაცია წარმატებით დასრულდა. სამაგიეროდ დააექსპორტეთ. ასლი, რომელიც უკვე ემთხვევა პროდაქშენს, ყველაზე იაფი გარემოა შემდეგი ცვლილებისთვის, ინციდენტის უსაფრთხოდ გასამეორებლად და ახალი ინჟინრის შესაყვანად — ადამიანს შეუძლია რეალური ქსელის ასლი გააფუჭოს შედეგების გარეშე, და ეს გაცილებით უკეთესი გაცნობაა, ვიდრე სქემის კითხვა.

ამგვარი რეპეტიციის ყველაზე ღირსი ცვლილებებია ის, რომელთა დაზიანების რადიუსიც ფართოა: მარშრუტიზაციის პოლიტიკის რედაქტირება, რაც აღწერილია სტატიაში BGP traffic engineering flow მონაცემებით, და ყველაფერი, რაც თქვენი პრეფიქსების წარმოშობას ეხება — იხილეთ RIPE NCC-ის რესურსები თავიდან ბოლომდე.