როგორ აიღოთ თქვენი ქსელის ინფრასტრუქტურის კონტროლი. თავი მეორე. დასუფთავება და დოკუმენტაცია

ეს სტატია არის მეორე სტატიების სერიიდან „როგორ აიღოთ კონტროლი თქვენი ქსელის ინფრასტრუქტურაზე“. სერიის ყველა სტატიის შინაარსი და ბმულები შეგიძლიათ იხილოთ აქ.

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

ახლა ჩვენ აღარ ვისაუბრებთ უსაფრთხოების აუდიტებზე - ეს იქნება მესამე ნაწილის თემა.

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

იდეალური მდგომარეობაა, როცა

• თქვენი ქსელი შეიქმნა პროექტის შესაბამისად და თქვენ გაქვთ დოკუმენტების სრული ნაკრები
• დანერგილია თქვენს კომპანიაში კონტროლისა და მართვის პროცესის შეცვლა ქსელისთვის
• ამ პროცესის შესაბამისად, თქვენ გაქვთ დოკუმენტები (მათ შორის, ყველა საჭირო დიაგრამა), რომელიც უზრუნველყოფს სრულ ინფორმაციას საქმის მიმდინარე მდგომარეობის შესახებ

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

უარეს შემთხვევაში, გექნებათ

• ქსელი, რომელიც შექმნილია პროექტის, გეგმის, დამტკიცების გარეშე, ინჟინრების მიერ, რომლებსაც არ გააჩნიათ საკმარისი დონის კვალიფიკაცია,
• ქაოტური, დაუსაბუთებელი ცვლილებებით, ბევრი „ნაგვით“ და არაოპტიმალური გადაწყვეტილებებით

გასაგებია, რომ თქვენი მდგომარეობა სადღაც შუაშია, მაგრამ სამწუხაროდ, ამ სკალაზე უკეთესი - უარესი, დიდია ალბათობა იმისა, რომ უარეს დასასრულს მიუახლოვდებით.

ამ შემთხვევაში, თქვენ ასევე დაგჭირდებათ აზრების წაკითხვის უნარი, რადგან თქვენ უნდა ისწავლოთ იმის გაგება, თუ რისი გაკეთება სურდათ „დიზაინერებს“, აღადგინოთ ლოგიკა, დაასრულოთ ის, რაც არ იყო დასრულებული და ამოიღოთ „ნაგავი“.
და, რა თქმა უნდა, დაგჭირდებათ მათი შეცდომების გამოსწორება, დიზაინის შეცვლა (ამ ეტაპზე რაც შეიძლება მინიმალურად) და სქემების შეცვლა ან ხელახლა შექმნა.

ეს სტატია არანაირად არ აცხადებს, რომ სრულია. აქ მე აღვწერ მხოლოდ ზოგად პრინციპებს და ყურადღებას გავამახვილებ ზოგიერთ საერთო პრობლემაზე, რომლებიც უნდა გადაიჭრას.

დოკუმენტების ნაკრები

დავიწყოთ მაგალითით.

ქვემოთ მოცემულია რამდენიმე დოკუმენტი, რომლებიც ჩვეულებრივ იქმნება Cisco Systems-ში დიზაინის დროს.

CR – მომხმარებლის მოთხოვნები, კლიენტის მოთხოვნები (ტექნიკური მახასიათებლები).
იგი იქმნება მომხმარებელთან ერთად და განსაზღვრავს ქსელის მოთხოვნებს.

HLD – მაღალი დონის დიზაინი, მაღალი დონის დიზაინი, რომელიც ეფუძნება ქსელის მოთხოვნებს (CR). დოკუმენტი განმარტავს და ამართლებს მიღებულ არქიტექტურულ გადაწყვეტილებებს (ტოპოლოგია, პროტოკოლები, ტექნიკის შერჩევა,...). HLD არ შეიცავს დიზაინის დეტალებს, როგორიცაა გამოყენებული ინტერფეისები და IP მისამართები. ასევე, კონკრეტული ტექნიკის კონფიგურაცია აქ არ არის განხილული. პირიქით, ეს დოკუმენტი მიზნად ისახავს აუხსნას ძირითადი დიზაინის კონცეფციებს მომხმარებლის ტექნიკურ მენეჯმენტს.

LLD - დაბალი დონის დიზაინი, დაბალი დონის დიზაინი, რომელიც დაფუძნებულია მაღალი დონის დიზაინზე (HLD).
ის უნდა შეიცავდეს ყველა დეტალს, რომელიც აუცილებელია პროექტის განსახორციელებლად, როგორიცაა ინფორმაცია აღჭურვილობის დაკავშირებისა და კონფიგურაციის შესახებ. ეს არის სრული სახელმძღვანელო დიზაინის განხორციელებისთვის. ამ დოკუმენტმა უნდა უზრუნველყოს საკმარისი ინფორმაცია მისი განხორციელებისთვის თუნდაც ნაკლებად კვალიფიციური პერსონალის მიერ.

რაღაც, მაგალითად, IP მისამართები, AS ნომრები, ფიზიკური გადართვის სქემა (კაბელი), შეიძლება „გამოიტანოს“ ცალკეულ დოკუმენტებში, მაგ. NIP (ქსელის განხორციელების გეგმა).

ქსელის მშენებლობა იწყება ამ დოკუმენტების შექმნის შემდეგ და ხდება მათი მკაცრი დაცვით და შემდეგ მოწმდება მომხმარებლის მიერ (ტესტები) დიზაინთან შესაბამისობაში.

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

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

ეს არის შემდეგი დოკუმენტები:

• ფიზიკური გადართვის (კაბელის) დიაგრამა (ლოგი)
• ქსელის დიაგრამა ან დიაგრამები L2/L3 არსებითი ინფორმაციით

ფიზიკური გადართვის დიაგრამა

ზოგიერთ მცირე კომპანიაში აღჭურვილობის დამონტაჟებასთან და ფიზიკურ გადართვასთან (კაბელთან) დაკავშირებული სამუშაოები ქსელის ინჟინრების პასუხისმგებლობაა.

ამ შემთხვევაში, პრობლემა ნაწილობრივ მოგვარებულია შემდეგი მიდგომით.

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

ეს მოგცემთ შესაძლებლობას, თუნდაც ლინკთან დაკავშირებული პრობლემის შემთხვევაში (როდესაც cdp ან lldp არ მუშაობს ამ ინტერფეისზე), სწრაფად დაადგინოთ რა არის დაკავშირებული ამ პორტთან.
თქვენ ასევე შეგიძლიათ მარტივად ნახოთ რომელი პორტებია დაკავებული და რომელი თავისუფალი, რაც აუცილებელია ახალი ქსელური აღჭურვილობის, სერვერების ან სამუშაო სადგურების კავშირების დასაგეგმად.

მაგრამ ცხადია, რომ თუ თქვენ დაკარგავთ წვდომას აღჭურვილობაზე, თქვენ ასევე დაკარგავთ წვდომას ამ ინფორმაციაზე. გარდა ამისა, ამ გზით თქვენ ვერ შეძლებთ ისეთი მნიშვნელოვანი ინფორმაციის ჩაწერას, როგორიცაა რა სახის აღჭურვილობა, რა ენერგომოხმარება, რამდენ პორტშია, რომელ თაროშია, რა პაჩ პანელები არის და სად (რა თაროზე/პაჩ პანელში ) ისინი დაკავშირებულია. ამიტომ, დამატებითი დოკუმენტაცია (არა მხოლოდ აღჭურვილობის აღწერილობები) კვლავ ძალიან სასარგებლოა.

იდეალური ვარიანტია ამ ტიპის ინფორმაციასთან მუშაობისთვის შექმნილი აპლიკაციების გამოყენება. მაგრამ შეგიძლიათ შემოიფარგლოთ მარტივი ცხრილებით (მაგალითად, Excel-ში) ან აჩვენოთ ინფორმაცია, რომელსაც საჭიროდ მიიჩნევთ L1/L2 დიაგრამებში.

მნიშვნელოვანია!

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

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

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

ქსელის დიაგრამები

არ არსებობს უნივერსალური მიდგომა დიაგრამების შედგენისას.

ყველაზე მნიშვნელოვანი ის არის, რომ დიაგრამებმა უნდა უზრუნველყოს იმის გაგება, თუ როგორ წარიმართება ტრაფიკი, რომელ ლოგიკურ და ფიზიკურ ელემენტებს შორისაა თქვენი ქსელი.

ფიზიკურ ელემენტებში ვგულისხმობთ

• აქტიური აღჭურვილობა
• აქტიური აღჭურვილობის ინტერფეისები/პორტები

ლოგიკურად -

• ლოგიკური მოწყობილობები (N7K VDC, Palo Alto VSYS, ...)
• VRF
• ვილანები
• ქვეინტერფეისები
• გვირაბები
• ზონა
• ...

ასევე, თუ თქვენი ქსელი არ არის სრულიად ელემენტარული, ის შედგება სხვადასხვა სეგმენტებისგან.
მაგალითად

• მონაცემთა ცენტრი
• ინტერნეტ
• WAN
• დისტანციური წვდომა
• საოფისე LAN
• DMZ
• ...

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

ვინაიდან თანამედროვე ქსელებში შეიძლება იყოს ბევრი ლოგიკური ფენა, შესაძლოა კარგი (მაგრამ არა აუცილებელი) მიდგომაა სხვადასხვა ფენისთვის სხვადასხვა სქემების შექმნა, მაგალითად, გადაფარვის მიდგომის შემთხვევაში ეს შეიძლება იყოს შემდეგი სქემები:

• overlay
• L1/L2 ქვედაფენი
• L3 ქვედაფენი

რა თქმა უნდა, ყველაზე მნიშვნელოვანი დიაგრამა, რომლის გარეშეც შეუძლებელია თქვენი დიზაინის იდეის გაგება, არის მარშრუტიზაციის დიაგრამა.

მარშრუტის სქემა

მინიმუმ, ეს დიაგრამა უნდა აისახოს

• რა მარშრუტიზაციის პროტოკოლები გამოიყენება და სად
• ძირითადი ინფორმაცია მარშრუტიზაციის პროტოკოლის პარამეტრების შესახებ (არეალი/AS ნომერი/როუტერის ID/…)
• რომელ მოწყობილობებზე ხდება გადანაწილება?
• სადაც ხდება ფილტრაცია და მარშრუტების აგრეგაცია
• ნაგულისხმევი მარშრუტის ინფორმაცია

ასევე, L2 სქემა (OSI) ხშირად სასარგებლოა.

L2 სქემა (OSI)

ეს დიაგრამა შეიძლება აჩვენოს შემდეგი ინფორმაცია:

• რა VLAN-ები
• რომელი პორტებია მაგისტრალური პორტები
• რომელი პორტები აგრეგირებულია ეთერ-არხში (პორტის არხი), ვირტუალური პორტის არხი
• რა STP პროტოკოლები გამოიყენება და რა მოწყობილობებზე
• ძირითადი STP პარამეტრები: root/root სარეზერვო, STP ღირებულება, პორტის პრიორიტეტი
• დამატებითი STP პარამეტრები: BPDU მცველი/ფილტრი, root მცველი…

ტიპიური დიზაინის შეცდომები

ქსელის აშენების ცუდი მიდგომის მაგალითი.

ავიღოთ მარტივი საოფისე LAN-ის აგების მარტივი მაგალითი.

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

რა რთულია გადამრთველების ერთმანეთთან დაკავშირება, VLAN-ების, SVI ინტერფეისების დაყენება (L3 გადამრთველების შემთხვევაში) და სტატიკური მარშრუტიზაციის დაყენება?

ყველაფერი იმუშავებს.

მაგრამ ამავე დროს, კითხვები დაკავშირებულია

• უსაფრთხოება
• დაჯავშნა
• ქსელის მასშტაბირება
• პროდუქტიულობა
• გამტარუნარიანობა
• საიმედოობა
• ...

დროდადრო მესმის განცხადება, რომ ოფისის LAN არის რაღაც ძალიან მარტივი და ამას ჩვეულებრივ მესმის ინჟინრებისგან (და მენეჯერებისგან), რომლებიც ყველაფერს აკეთებენ ქსელების გარდა, და ისინი ამას ისე თავდაჯერებულად ამბობენ, რომ არ გაგიკვირდეთ, თუ LAN იქნება. დამზადებულია არასაკმარისი პრაქტიკის და ცოდნის მქონე ადამიანების მიერ და დაშვებული იქნება დაახლოებით იგივე შეცდომებით, რომლებსაც ქვემოთ აღვწერ.

საერთო L1 (OSI) დიზაინის შეცდომები

• თუ, მიუხედავად ამისა, თქვენ ასევე ხართ პასუხისმგებელი SCS-ზე, მაშინ ერთ-ერთი ყველაზე უსიამოვნო მემკვიდრეობა, რომელიც შეიძლება მიიღოთ, არის უყურადღებო და ცუდად მოფიქრებული შეცვლა.

მე ასევე დავახარისხებ, როგორც ტიპის L1 შეცდომებს, რომლებიც დაკავშირებულია გამოყენებული აღჭურვილობის რესურსებთან, მაგალითად,

• არასაკმარისი გამტარობა
• არასაკმარისი TCAM აღჭურვილობაზე (ან მისი არაეფექტური გამოყენება)
• არასაკმარისი შესრულება (ხშირად დაკავშირებულია Firewall-თან)

საერთო L2 (OSI) დიზაინის შეცდომები

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

შედეგად, ხშირად გვაქვს შემდეგი

• STP ქსელის დიდი დიამეტრი, რამაც შეიძლება გამოიწვიოს სამაუწყებლო შტორმები
• STP root განისაზღვრება შემთხვევით (მაკ მისამართზე დაყრდნობით) და ტრაფიკის გზა იქნება არაოპტიმალური
• ჰოსტებთან დაკავშირებული პორტები არ იქნება კონფიგურირებული როგორც edge (portfast), რაც გამოიწვევს STP-ის ხელახლა გამოთვლას ბოლო სადგურების ჩართვა/გამორთვისას
• ქსელი არ იქნება სეგმენტირებული L1/L2 დონეზე, რის შედეგადაც რაიმე გადამრთველთან დაკავშირებული პრობლემები (მაგალითად, დენის გადატვირთვა) გამოიწვევს STP ტოპოლოგიის ხელახლა გამოთვლას და ტრაფიკის შეჩერებას ყველა VLAN-ში ყველა გადამრთველზე (მათ შორის ერთი კრიტიკული უწყვეტობის სერვისის სეგმენტის თვალსაზრისით)

შეცდომების მაგალითები L3 (OSI) დიზაინში

დამწყები ქსელების რამდენიმე ტიპიური შეცდომა:

• სტატიკური მარშრუტის ხშირი გამოყენება (ან მხოლოდ გამოყენება).
• არაოპტიმალური მარშრუტიზაციის პროტოკოლების გამოყენება მოცემული დიზაინისთვის
• არაოპტიმალური ლოგიკური ქსელის სეგმენტაცია
• მისამართების სივრცის არაოპტიმალური გამოყენება, რომელიც არ იძლევა მარშრუტების აგრეგაციას
• არ არის სარეზერვო მარშრუტები
• ნაგულისხმევი კარიბჭის დაჯავშნა არ არის
• ასიმეტრიული მარშრუტიზაცია მარშრუტების აღდგენისას (შეიძლება იყოს კრიტიკული NAT/PAT-ის შემთხვევაში, სახელმწიფო ფაიერვოლებით)
• პრობლემები MTU-სთან
• როდესაც მარშრუტები აღდგენილია, მოძრაობა გადის უსაფრთხოების სხვა ზონებში ან თუნდაც სხვა ფეიერვოლებით, რაც იწვევს ამ ტრაფიკის შეწყვეტას
• ცუდი ტოპოლოგიის მასშტაბურობა

დიზაინის ხარისხის შეფასების კრიტერიუმები

როდესაც ვსაუბრობთ ოპტიმალურობა/არაოპტიმალურობაზე, უნდა გვესმოდეს, რა კრიტერიუმებით შეგვიძლია ამის შეფასება. აქ, ჩემი აზრით, არის ყველაზე მნიშვნელოვანი (მაგრამ არა ყველა) კრიტერიუმი (და ახსნა მარშრუტიზაციის პროტოკოლებთან დაკავშირებით):

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

ცვლილებები

ამ ეტაპზე ძირითადი პრინციპი შეიძლება გამოიხატოს ფორმულით "არ დააზიანო".
ამიტომ, მაშინაც კი, თუ სრულად არ ეთანხმებით დიზაინს და არჩეულ განხორციელებას (კონფიგურაციას), ყოველთვის არ არის მიზანშეწონილი ცვლილებების შეტანა. გონივრული მიდგომაა ყველა გამოვლენილი პრობლემის რანჟირება ორი პარამეტრის მიხედვით:

• რამდენად მარტივად შეიძლება ამ პრობლემის გამოსწორება
• რამდენი რისკი აქვს მას?

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

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

წყარო: www.habr.com