Ένας σημαντικός αριθμός εταιρικών εφαρμογών και συστημάτων εικονικοποίησης έχουν τους δικούς τους μηχανισμούς για τη δημιουργία λύσεων ανεκτικών σφαλμάτων. Συγκεκριμένα, το Oracle RAC (Oracle Real Application Cluster) είναι ένα σύμπλεγμα δύο ή περισσότερων διακομιστών βάσης δεδομένων Oracle που συνεργάζονται για να εξισορροπήσουν το φορτίο και να παρέχουν ανοχή σφαλμάτων σε επίπεδο διακομιστή/εφαρμογής. Για να εργαστείτε σε αυτήν τη λειτουργία, χρειάζεστε έναν κοινόχρηστο χώρο αποθήκευσης, ο οποίος είναι συνήθως ένα σύστημα αποθήκευσης.
Όπως έχουμε ήδη συζητήσει σε ένα από μας , το ίδιο το σύστημα αποθήκευσης, παρά την παρουσία διπλών στοιχείων (συμπεριλαμβανομένων των ελεγκτών), εξακολουθεί να έχει σημεία αστοχίας - κυρίως με τη μορφή ενός ενιαίου συνόλου δεδομένων. Επομένως, για να δημιουργηθεί μια λύση Oracle με αυξημένες απαιτήσεις αξιοπιστίας, το σχήμα «N servers - one storage system» πρέπει να είναι πολύπλοκο.
Πρώτα, φυσικά, πρέπει να αποφασίσουμε από ποιους κινδύνους προσπαθούμε να ασφαλίσουμε. Σε αυτό το άρθρο, δεν θα εξετάσουμε την προστασία από απειλές όπως "Έφτασε ένας μετεωρίτης". Έτσι, η δημιουργία μιας γεωγραφικά διεσπαρμένης λύσης αποκατάστασης καταστροφών θα παραμείνει θέμα για ένα από τα ακόλουθα άρθρα. Εδώ θα εξετάσουμε τη λεγόμενη λύση Cross-Rack Disaster Recovery, όταν η προστασία ενσωματώνεται σε επίπεδο γραφείων διακομιστή. Τα ίδια τα ντουλάπια μπορούν να βρίσκονται στο ίδιο δωμάτιο ή σε διαφορετικά, αλλά συνήθως μέσα στο ίδιο κτίριο.
Αυτά τα ντουλάπια πρέπει να περιέχουν όλο το απαραίτητο σύνολο εξοπλισμού και λογισμικού που θα επιτρέψει τη λειτουργία των βάσεων δεδομένων της Oracle ανεξάρτητα από την κατάσταση του «γείτονα». Με άλλα λόγια, χρησιμοποιώντας τη λύση ανάκτησης καταστροφών Cross-Rack, εξαλείφουμε τους κινδύνους αποτυχίας:
- Διακομιστές εφαρμογών Oracle
- Συστήματα αποθήκευσης
- Συστήματα μεταγωγής
- Πλήρης αποτυχία όλου του εξοπλισμού στο ντουλάπι:
- Άρνηση εξουσίας
- Αστοχία συστήματος ψύξης
- Εξωτερικοί παράγοντες (άνθρωπος, φύση κ.λπ.)
Η αντιγραφή των διακομιστών Oracle συνεπάγεται την ίδια την αρχή λειτουργίας του Oracle RAC και υλοποιείται μέσω μιας εφαρμογής. Δεν αποτελεί επίσης πρόβλημα η επικάλυψη των εγκαταστάσεων μεταγωγής. Αλλά με την αντιγραφή του συστήματος αποθήκευσης, όλα δεν είναι τόσο απλά.
Η απλούστερη επιλογή είναι η αναπαραγωγή δεδομένων από το κύριο σύστημα αποθήκευσης στο εφεδρικό. Σύγχρονη ή ασύγχρονη, ανάλογα με τις δυνατότητες του συστήματος αποθήκευσης. Με την ασύγχρονη αναπαραγωγή, τίθεται αμέσως το ερώτημα της διασφάλισης της συνέπειας των δεδομένων σε σχέση με την Oracle. Αλλά ακόμα και αν υπάρχει ενσωμάτωση λογισμικού με την εφαρμογή, σε κάθε περίπτωση, σε περίπτωση αστοχίας στο κύριο σύστημα αποθήκευσης, θα απαιτηθεί χειροκίνητη παρέμβαση από τους διαχειριστές προκειμένου να αλλάξει το σύμπλεγμα σε εφεδρικό χώρο αποθήκευσης.
Μια πιο σύνθετη επιλογή είναι οι "virtualizers" αποθήκευσης λογισμικού ή/και υλικού που θα εξαλείψουν προβλήματα συνέπειας και χειροκίνητη παρέμβαση. Αλλά η πολυπλοκότητα της ανάπτυξης και της επακόλουθης διαχείρισης, καθώς και το πολύ απρεπές κόστος τέτοιων λύσεων, τρομάζει πολλούς.
Η λύση AccelStor NeoSapphire™ All Flash Array είναι ιδανική για σενάρια όπως η ανάκτηση από καταστροφές Cross-Rack χρησιμοποιώντας την αρχιτεκτονική Shared-Nothing. Αυτό το μοντέλο είναι ένα σύστημα αποθήκευσης δύο κόμβων που χρησιμοποιεί αποκλειστική τεχνολογία FlexiRemap® για εργασία με μονάδες flash. Χάρη σε Το NeoSapphire™ H710 είναι ικανό να προσφέρει απόδοση έως και 600K IOPS@4K τυχαίας εγγραφής και 1M+ IOPS@4K τυχαίας ανάγνωσης, κάτι που είναι ανέφικτο όταν χρησιμοποιείτε κλασικά συστήματα αποθήκευσης που βασίζονται σε RAID.
Αλλά το κύριο χαρακτηριστικό του NeoSapphire™ H710 είναι η εκτέλεση δύο κόμβων με τη μορφή ξεχωριστών περιπτώσεων, καθένας από τους οποίους έχει το δικό του αντίγραφο των δεδομένων. Ο συγχρονισμός των κόμβων πραγματοποιείται μέσω της εξωτερικής διεπαφής InfiniBand. Χάρη σε αυτήν την αρχιτεκτονική, είναι δυνατή η διανομή κόμβων σε διαφορετικές τοποθεσίες σε απόσταση έως και 100 μέτρων, παρέχοντας έτσι μια λύση ανάκτησης καταστροφών Cross-Rack. Και οι δύο κόμβοι λειτουργούν εντελώς συγχρονισμένα. Από την πλευρά του κεντρικού υπολογιστή, το H710 μοιάζει με ένα συνηθισμένο σύστημα αποθήκευσης διπλού ελεγκτή. Επομένως, δεν χρειάζεται να εκτελέσετε πρόσθετες επιλογές λογισμικού ή υλικού ή ιδιαίτερα περίπλοκες ρυθμίσεις.
Εάν συγκρίνουμε όλες τις λύσεις ανάκτησης καταστροφών Cross-Rack που περιγράφονται παραπάνω, τότε η επιλογή από το AccelStor ξεχωρίζει αισθητά από τις υπόλοιπες:
AccelStor NeoSapphire™ Shared Nothing Architecture
Σύστημα αποθήκευσης "virtualizer" λογισμικού ή υλικού
Λύση με βάση την αναπαραγωγή
Διαθεσιμότητα
Αποτυχία διακομιστή
Χωρίς διακοπή
Χωρίς διακοπή
Χωρίς διακοπή
Αποτυχία διακόπτη
Χωρίς διακοπή
Χωρίς διακοπή
Χωρίς διακοπή
Αποτυχία συστήματος αποθήκευσης
Χωρίς διακοπή
Χωρίς διακοπή
Downtime
Ολόκληρη η αποτυχία του ντουλαπιού
Χωρίς διακοπή
Χωρίς διακοπή
Downtime
Κόστος και πολυπλοκότητα
Κόστος λύσης
Χαμηλός*
Υψηλός
Υψηλός
Πολυπλοκότητα ανάπτυξης
Χαμηλή
Υψηλός
Υψηλός
*Το AccelStor NeoSapphire™ εξακολουθεί να είναι μια συστοιχία All Flash, η οποία εξ ορισμού δεν κοστίζει «3 καπίκια», ειδικά επειδή έχει διπλή χωρητικότητα. Ωστόσο, όταν συγκρίνετε το τελικό κόστος μιας λύσης που βασίζεται σε αυτήν με παρόμοια από άλλους προμηθευτές, το κόστος μπορεί να θεωρηθεί χαμηλό.
Η τοπολογία για τη σύνδεση διακομιστών εφαρμογών και Όλοι οι κόμβοι συστοιχίας Flash θα μοιάζει με αυτό:
Κατά τον σχεδιασμό της τοπολογίας, συνιστάται επίσης να αντιγράψετε τους διακόπτες διαχείρισης και τους διακομιστές διασύνδεσης.
Εδώ και περαιτέρω θα μιλήσουμε για σύνδεση μέσω Fiber Channel. Εάν χρησιμοποιείτε iSCSI, όλα θα είναι ίδια, προσαρμοσμένα για τους τύπους των διακοπτών που χρησιμοποιούνται και ελαφρώς διαφορετικές ρυθμίσεις πίνακα.
Προπαρασκευαστικές εργασίες στον πίνακα
Εξοπλισμός και λογισμικό που χρησιμοποιείται
Προδιαγραφές διακομιστή και διακόπτη
Εξαρτήματα
Περιγραφή
Διακομιστές Oracle Database 11g
Δύο
Λειτουργικό σύστημα διακομιστή
Oracle Linux
Έκδοση βάσης δεδομένων Oracle
11 g (RAC)
Επεξεργαστές ανά διακομιστή
Δύο 16 πυρήνες Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Φυσική μνήμη ανά διακομιστή
128GB
δίκτυο FC
16Gb/s FC με πολλαπλή διαδρομή
FC HBA
Emulex Lpe-16002B
Αποκλειστικές δημόσιες θύρες 1GbE για διαχείριση συμπλέγματος
Προσαρμογέας Intel ethernet RJ45
Διακόπτης FC 16Gb/s
Μπροκάρ 6505
Αποκλειστικές ιδιωτικές θύρες 10 GbE για συγχρονισμό δεδομένων
Intel X520
Προδιαγραφές AccelStor NeoSapphire™ All Flash Array
Εξαρτήματα
Περιγραφή
Σύστημα αποθήκευσης
Μοντέλο υψηλής διαθεσιμότητας NeoSapphire™: H710
Έκδοση εικόνας
4.0.1
Συνολικός αριθμός μονάδων δίσκου
48
Μέγεθος δίσκου
1.92TB
Τύπος μονάδας δίσκου
SSD
Θύρες στόχου FC
Θύρες 16x 16Gb (8 ανά κόμβο)
Λιμένες διαχείρισης
Το καλώδιο ethernet 1GbE που συνδέεται με κεντρικούς υπολογιστές μέσω ενός διακόπτη ethernet
Θύρα χτύπου της καρδιάς
Το καλώδιο ethernet 1GbE που συνδέεται μεταξύ δύο κόμβων αποθήκευσης
Θύρα συγχρονισμού δεδομένων
Καλώδιο InfiniBand 56 Gb/s
Για να μπορέσετε να χρησιμοποιήσετε έναν πίνακα, πρέπει να τον αρχικοποιήσετε. Από προεπιλογή, η διεύθυνση ελέγχου και των δύο κόμβων είναι η ίδια (192.168.1.1). Πρέπει να συνδεθείτε σε αυτές μία προς μία και να ορίσετε νέες (ήδη διαφορετικές) διευθύνσεις διαχείρισης και να ρυθμίσετε το συγχρονισμό χρόνου, μετά τον οποίο οι θύρες διαχείρισης μπορούν να συνδεθούν σε ένα μόνο δίκτυο. Στη συνέχεια, οι κόμβοι συνδυάζονται σε ένα ζεύγος HA με την ανάθεση υποδικτύων για συνδέσεις Interlink.
Αφού ολοκληρωθεί η προετοιμασία, μπορείτε να διαχειριστείτε τον πίνακα από οποιονδήποτε κόμβο.
Στη συνέχεια, δημιουργούμε τους απαραίτητους τόμους και τους δημοσιεύουμε στους διακομιστές εφαρμογών.
Συνιστάται ιδιαίτερα η δημιουργία πολλών τόμων για το Oracle ASM, καθώς αυτό θα αυξήσει τον αριθμό των στόχων για τους διακομιστές, γεγονός που θα βελτιώσει τελικά τη συνολική απόδοση (περισσότερα για τις ουρές σε άλλο ).
Διαμόρφωση δοκιμής
Όνομα τόμου αποθήκευσης
Μέγεθος όγκου
Δεδομένα01
200GB
Δεδομένα02
200GB
Δεδομένα03
200GB
Δεδομένα04
200GB
Δεδομένα05
200GB
Δεδομένα06
200GB
Δεδομένα07
200GB
Δεδομένα08
200GB
Δεδομένα09
200GB
Δεδομένα10
200GB
Πλέγμα01
1GB
Πλέγμα02
1GB
Πλέγμα03
1GB
Πλέγμα04
1GB
Πλέγμα05
1GB
Πλέγμα06
1GB
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Μερικές επεξηγήσεις σχετικά με τους τρόπους λειτουργίας της συστοιχίας και τις διεργασίες που συμβαίνουν σε καταστάσεις έκτακτης ανάγκης
Το σύνολο δεδομένων κάθε κόμβου έχει μια παράμετρο "αριθμός έκδοσης". Μετά την αρχική αρχικοποίηση, είναι το ίδιο και ίσο με 1. Εάν για κάποιο λόγο ο αριθμός έκδοσης είναι διαφορετικός, τότε τα δεδομένα συγχρονίζονται πάντα από την παλαιότερη έκδοση στη νεότερη, μετά από την οποία ευθυγραμμίζεται ο αριθμός της νεότερης έκδοσης, π.χ. Αυτό σημαίνει ότι τα αντίγραφα είναι πανομοιότυπα. Λόγοι για τους οποίους οι εκδόσεις μπορεί να είναι διαφορετικές:
- Προγραμματισμένη επανεκκίνηση ενός από τους κόμβους
- Ατύχημα σε έναν από τους κόμβους λόγω ξαφνικής διακοπής λειτουργίας (τροφοδοσία, υπερθέρμανση κ.λπ.).
- Χάθηκε η σύνδεση InfiniBand με αδυναμία συγχρονισμού
- Συντριβή σε έναν από τους κόμβους λόγω καταστροφής δεδομένων. Εδώ θα χρειαστεί να δημιουργήσετε μια νέα ομάδα HA και να ολοκληρώσετε τον συγχρονισμό του συνόλου δεδομένων.
Σε κάθε περίπτωση, ο κόμβος που παραμένει συνδεδεμένος αυξάνει τον αριθμό έκδοσής του κατά ένα προκειμένου να συγχρονίσει το σύνολο δεδομένων του μετά την αποκατάσταση της σύνδεσης με το ζεύγος.
Εάν χαθεί η σύνδεση μέσω της σύνδεσης Ethernet, το Heartbeat μεταβαίνει προσωρινά στο InfiniBand και επιστρέφει εντός 10 δευτερολέπτων όταν αποκατασταθεί.
Ρύθμιση κεντρικών υπολογιστών
Για να διασφαλίσετε την ανοχή σφαλμάτων και να βελτιώσετε την απόδοση, πρέπει να ενεργοποιήσετε την υποστήριξη MPIO για τη συστοιχία. Για να το κάνετε αυτό, πρέπει να προσθέσετε γραμμές στο αρχείο /etc/multipath.conf και, στη συνέχεια, να επανεκκινήσετε την υπηρεσία πολλαπλών διαδρομών
Κρυφό κείμενοσυσκευές {
συσκευή {
πωλητής "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
χαρακτηριστικά "0"
hardware_handler "0"
prio "const"
αποτυχία άμεση
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ναι
detect_prio ναι
rr_min_io_rq 1
no_path_retry 0
}
}
Στη συνέχεια, για να λειτουργήσει το ASM με το MPIO μέσω ASMLib, πρέπει να αλλάξετε το αρχείο /etc/sysconfig/oracleasm και μετά να εκτελέσετε το /etc/init.d/oracleasm scandisks
Κρυφό κείμενο
# ORACLEASM_SCANORDER: Αντιστοίχιση μοτίβων με παραγγελία σάρωση δίσκου
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Αντιστοίχιση μοτίβων για εξαίρεση δίσκων από τη σάρωση
ORACLEASM_SCANEXCLUDE="sd"
Σημείωση
Εάν δεν θέλετε να χρησιμοποιήσετε το ASMLib, μπορείτε να χρησιμοποιήσετε τους κανόνες UDEV, οι οποίοι αποτελούν τη βάση για το ASMLib.
Ξεκινώντας με την έκδοση 12.1.0.2 της Oracle Database, η επιλογή είναι διαθέσιμη για εγκατάσταση ως μέρος του λογισμικού ASMFD.
Είναι επιτακτική ανάγκη να διασφαλίσετε ότι οι δίσκοι που δημιουργήθηκαν για το Oracle ASM είναι ευθυγραμμισμένοι με το μέγεθος μπλοκ με το οποίο λειτουργεί φυσικά η συστοιχία (4K). Διαφορετικά, ενδέχεται να προκύψουν προβλήματα απόδοσης. Επομένως, είναι απαραίτητο να δημιουργηθούν τόμοι με τις κατάλληλες παραμέτρους:
χωριστή /dev/mapper/device-name mklabel gpt mkpart main 2048s 100% align-check βέλτιστη 1
Κατανομή βάσεων δεδομένων σε τόμους που δημιουργήθηκαν για τη διαμόρφωση δοκιμής μας
Όνομα τόμου αποθήκευσης
Μέγεθος όγκου
Χαρτογράφηση όγκου LUN
Λεπτομέρεια συσκευής τόμου ASM
Μέγεθος μονάδας κατανομής
Δεδομένα01
200GB
Αντιστοιχίστε όλους τους όγκους αποθήκευσης σε όλες τις θύρες δεδομένων του συστήματος αποθήκευσης
Πλεονασμός: Κανονικό
Όνομα: DGDATA
Σκοπός: Αρχεία δεδομένων
300 ΜΒ
Δεδομένα02
200GB
Δεδομένα03
200GB
Δεδομένα04
200GB
Δεδομένα05
200GB
Δεδομένα06
200GB
Δεδομένα07
200GB
Δεδομένα08
200GB
Δεδομένα09
200GB
Δεδομένα10
200GB
Πλέγμα01
1GB
Πλεονασμός: Κανονικό
Όνομα: DGGRID1
Σκοπός: Πλέγμα: CRS και Ψηφοφορία
300 ΜΒ
Πλέγμα02
1GB
Πλέγμα03
1GB
Πλέγμα04
1GB
Πλεονασμός: Κανονικό
Όνομα: DGGRID2
Σκοπός: Πλέγμα: CRS και Ψηφοφορία
300 ΜΒ
Πλέγμα05
1GB
Πλέγμα06
1GB
Redo01
100GB
Πλεονασμός: Κανονικό
Όνομα: DGREDO1
Σκοπός: Επαναλάβετε το αρχείο καταγραφής του νήματος 1
300 ΜΒ
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Πλεονασμός: Κανονικό
Όνομα: DGREDO2
Σκοπός: Επαναλάβετε το αρχείο καταγραφής του νήματος 2
300 ΜΒ
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Ρυθμίσεις βάσης δεδομένων
- Μέγεθος μπλοκ = 8Κ
- Ανταλλαγή χώρου = 16 GB
- Απενεργοποίηση AMM (Αυτόματη διαχείριση μνήμης)
- Απενεργοποιήστε τις Διαφανείς Τεράστιες Σελίδες
Αλλες ρυθμίσεις
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # μην το ρυθμίσετε εάν χρησιμοποιείτε Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ σκληρό πλέγμα nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ Grid soft stack 10240
✓ grid hard stack 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle hard nofile 65536
✓ Oracle soft stack 10240
✓ Oracle hard stack 32768
✓ soft memlock 120795954
✓ σκληρό memlock 120795954
sqlplus "/as sysdba"
Αλλαγή του συνόλου συστήματος διεργασίες=2000 scope=spfile;
αλλαγή συνόλου συστήματος open_cursors=2000 scope=spfile;
αλλαγή συνόλου συστήματος session_cached_cursors=300 scope=spfile;
αλλαγή συνόλου συστήματος db_files=8192 scope=spfile;
Τεστ αποτυχίας
Για λόγους επίδειξης, το HammerDB χρησιμοποιήθηκε για την εξομοίωση ενός φορτίου OLTP. Διαμόρφωση HammerDB:
Αριθμός Αποθηκών
256
Συνολικές συναλλαγές ανά χρήστη
1000000000000
Εικονικοί Χρήστες
256
Το αποτέλεσμα ήταν 2.1M TPM, που απέχει πολύ από το όριο απόδοσης της συστοιχίας , αλλά αποτελεί «ανώτατο όριο» για την τρέχουσα διαμόρφωση υλικού των διακομιστών (κυρίως λόγω επεξεργαστών) και του αριθμού τους. Ο σκοπός αυτής της δοκιμής εξακολουθεί να είναι να αποδείξει την ανοχή σφαλμάτων της λύσης στο σύνολό της και όχι να επιτύχει τη μέγιστη απόδοση. Επομένως, θα βασιστούμε απλώς σε αυτό το σχήμα.
Δοκιμή για αποτυχία ενός από τους κόμβους
Οι οικοδεσπότες έχασαν μέρος των μονοπατιών προς το χώρο αποθήκευσης, συνεχίζοντας να εργάζονται μέσω των υπόλοιπων με τον δεύτερο κόμβο. Η απόδοση έπεσε για λίγα δευτερόλεπτα λόγω της ανακατασκευής των μονοπατιών και στη συνέχεια επέστρεψε στο κανονικό. Δεν υπήρξε διακοπή στο σέρβις.
Δοκιμή αστοχίας ντουλαπιού με όλο τον εξοπλισμό
Σε αυτήν την περίπτωση, η απόδοση έπεσε επίσης για μερικά δευτερόλεπτα λόγω της αναδιάρθρωσης των μονοπατιών και στη συνέχεια επέστρεψε στο μισό της αρχικής τιμής. Το αποτέλεσμα μειώθηκε στο μισό από το αρχικό λόγω του αποκλεισμού ενός διακομιστή εφαρμογών από τη λειτουργία. Ούτε υπήρξε διακοπή στο σέρβις.
Εάν υπάρχει ανάγκη να εφαρμοστεί μια ανεκτική λύση ανάκτησης καταστροφών Cross-Rack για την Oracle με λογικό κόστος και με μικρή προσπάθεια ανάπτυξης/διαχείρισης, τότε το Oracle RAC και η αρχιτεκτονική συνεργάζονται θα είναι μια από τις καλύτερες επιλογές. Αντί για το Oracle RAC, μπορεί να υπάρχει οποιοδήποτε άλλο λογισμικό που παρέχει ομαδοποίηση, το ίδιο DBMS ή συστήματα εικονικοποίησης, για παράδειγμα. Η αρχή της κατασκευής της λύσης θα παραμείνει η ίδια. Και η κατώτατη γραμμή είναι μηδέν για το RTO και το RPO.
Πηγή: www.habr.com