| มกราคม 8, 2021 |
วิธีเลือกคลาวด์เมื่อคุณต้องการความพร้อมใช้งานสูง |
| ธันวาคม 30, 2020 |
วิธีโคลนความพร้อมใช้งานในระบบคลาวด์ด้วยผลลัพธ์ที่ดีขึ้น
วิธีโคลนความพร้อมใช้งานในระบบคลาวด์ด้วยผลลัพธ์ที่ดีขึ้นเคล็ดลับจากภาพยนตร์ – หลายหลากMultiplicity เป็นภาพยนตร์ตลกแนววิทยาศาสตร์อเมริกัน ปีพ.ศ. 2539 นำแสดงโดยไมเคิลคีตันขณะที่ดั๊กคินนีย์คนงานก่อสร้างที่วุ่นวายและพยายามหาเวลาให้กับครอบครัวและงานที่ต้องการ เมื่อนักวิทยาศาสตร์เสนอที่จะโคลนเขาดั๊กตกลงที่จะทำตามตารางเวลาและภาระผูกพันของเขาให้ง่ายขึ้น แต่แล้วสำเนาของเขาก็เริ่มทำสำเนาของตัวเอง เมื่อทำสำเนาครั้งสุดท้ายประเด็นจะชัดเจน การโคลนนิ่งอาจไม่ใช่ทั้งหมดที่เกิดขึ้นหรืออย่างน้อยที่สุดก็มาพร้อมกับคำเตือนความท้าทายและผลข้างเคียงที่ชัดเจน Star Trek ตอนดั้งเดิมที่มีชื่อเสียง“ Trouble with Tribbles” แสดงให้เห็นถึงจุดที่คล้ายกัน เช่นเดียวกับการโคลนบนหน้าจอขนาดใหญ่ (หรือเล็ก) การโคลนนิ่งในระบบคลาวด์เป็นเครื่องมือที่ยอดเยี่ยม แต่ไม่ใช่โดยปราศจากความท้าทาย เคล็ดลับเพื่อให้ได้ผลลัพธ์ที่ดีขึ้นเมื่อคุณโคลนความพร้อมใช้งานในระบบคลาวด์1. โคลนระบบปฏิบัติการฟังดูชัดเจน แต่ฉันเห็นว่ามันเกิดขึ้นมากกว่าหนึ่งครั้งในสภาพแวดล้อมองค์กรจริง หากคุณโคลนระบบที่ไม่สามารถใช้งานได้โคลนนั้นจะใช้งานไม่ได้และมีปัญหาอย่างเท่าเทียมกันเมื่อคุณกู้คืน ตรวจสอบให้แน่ใจว่าโคลนที่คุณสร้างนั้นมาจากระบบปฏิบัติการและใช้งานได้จริง 2. ซิงค์ข้อมูลไปยังดิสก์และซิงค์ใหม่ในการกู้คืนความสมบูรณ์ของระบบไฟล์เป็นสิ่งสำคัญ หากคุณไม่มั่นใจว่าแอปพลิเคชันและ / หรือ VM ของคุณอยู่ในสถานะที่สอดคล้องกันผู้ขายส่วนใหญ่จะไม่รับประกันว่าจะได้รูปภาพที่สร้างขึ้น เนื่องจากสแน็ปช็อตจะจับเฉพาะข้อมูลที่เขียนลงในโวลุ่มของคุณในขณะที่ออกคำสั่ง snapshot สิ่งนี้อาจไม่รวมข้อมูลใด ๆ ที่ถูกแคชโดยแอปพลิเคชันหรือระบบปฏิบัติการ การตรวจสอบให้แน่ใจว่าข้อมูลได้รับการซิงค์อย่างถูกต้องกับระบบไฟล์เป็นขั้นตอนที่สำคัญและมีความสำคัญอย่างยิ่งในสภาพแวดล้อมคลัสเตอร์ ความสมบูรณ์ของระบบไฟล์ยังเป็นสิ่งสำคัญที่ควรคำนึงถึงเมื่อคุณกู้คืนจากรูปภาพ หากคุณกำลังใช้การจำลองข้อมูลและคุณกู้คืนอิมเมจเป็นซอร์สหรือเป้าหมายในคลัสเตอร์ตรวจสอบให้แน่ใจว่าทั้งสองโหนดซิงค์กันเป็นสิ่งสำคัญยิ่ง หากไม่ทำเช่นนั้นอาจทำให้เกิดข้อผิดพลาดของระบบไฟล์เมื่อเกิดการเฟลโอเวอร์หรือการสลับหรือแม้กระทั่งข้อมูลสูญหาย โคลนความพร้อมใช้งานในระบบคลาวด์เพื่อให้ได้ผลลัพธ์ที่คุณต้องการ 3. หยุดอินสแตนซ์ของคุณหลายสภาพแวดล้อมไม่ต้องการให้คุณหยุดอินสแตนซ์เพื่อสร้างอิมเมจและบางอย่างเช่น AWS จะทำตามขั้นตอนของการปิดโหนดก่อนทำการคัดลอกอย่างไรก็ตามเครื่องมือและไซต์จำนวนมากแนะนำให้ตรวจสอบว่าแอปพลิเคชันหยุดทำงานและมีการซิงค์การเข้าถึงระบบไฟล์อย่างเหมาะสมเพื่อหลีกเลี่ยงความเสียหายการสูญเสียความสมบูรณ์หรือการสร้างภาพที่มีปัญหาในการเริ่มต้นหยุดหรือเรียกใช้แอปพลิเคชันที่ติดตั้ง 4. ติดป้ายกำกับทุกอย่างในระบบคลาวด์ (โหนดดิสก์ NIC ทุกอย่าง)ในขณะที่การสร้างโคลนเป็นการดำเนินการที่ไม่เสียค่าใช้จ่าย แต่โดยทั่วไปแล้วดิสก์และส่วนประกอบที่เป็นผลลัพธ์จะไม่ได้ตัวอย่างเช่น AWS ระบุว่าคุณ“ ถูกเรียกเก็บเงินสำหรับสแนปชอตจนกว่าคุณจะยกเลิกการลงทะเบียนรูปภาพและลบสแนปชอต” เมื่อสิ่งต่างๆไม่ได้ติดป้ายกำกับการรู้ว่าอะไรถูกใช้งานหรือไม่ได้ใช้งานและสาเหตุที่สร้างขึ้นอาจกลายเป็นปัญหาได้ นอกจากนี้ยังต้องอยู่ภายใต้ความทรงจำที่หายวับไปหรือสมาธิที่ไม่ดีของสมาชิกในทีมที่มีอยู่ติดป้ายกำกับทุกอย่าง 5. ลูกพรุนโคลนและสแนปช็อตบ่อยๆ (ประหยัดค่าใช้จ่ายและลดอาการปวดหัว)การตัดแต่งสแน็ปช็อตและโคลนนิ่งเก่าไม่เพียง แต่จะช่วยประหยัดค่าใช้จ่าย แต่ยังช่วยลดอาการปวดหัวได้อีกด้วยสแน็ปช็อตที่เก่ากว่าเสี่ยงต่อการแนะนำช่องโหว่ที่ได้รับการแก้ไขหรือแก้ไขในสำเนาที่ใหม่กว่าในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าของ SIOS Technology Corp. ฉันเห็นผลลัพธ์โดยตรงเมื่อเราทำงานกับลูกค้าที่กู้คืนจากสแนปชอต พวกเขาพบปัญหาหลายประการเมื่อรีสตาร์ทแอปพลิเคชัน หลังจากแก้ไขปัญหาเราพบว่าโคลนกำลังใช้งานซอฟต์แวร์รักษาความปลอดภัยเวอร์ชันเก่า ข้อมูลรับรองและข้อมูลเมตาที่เก็บไว้ในโปรไฟล์ผู้ใช้จะไม่ซิงค์กับข้อมูลแอปพลิเคชันจริงที่เก็บไว้ในไดรฟ์ข้อมูลที่ติดตั้งภายนอกอีกต่อไป 6. จำกัด หรือ จำกัด การโคลนโคลนในระบบคลาวด์สุดท้ายนี้ไม่ใช่ทุกสิ่งที่คุณทำในระบบคลาวด์จะต้องถูกโคลน พิจารณา จำกัด ประเภทของเวิร์กโหลดที่คุณจะโคลนและ จำกัด จำนวนหรือบทบาทที่สามารถสร้างโคลนในสภาพแวดล้อมของคุณ ในภาพยนตร์เมื่อโคลนของ Doug ได้จุดประกายชุดการทำสำเนาของตัวเอง Doug (Michael Keaton) ที่ถูกครอบงำแล้วถูกบังคับให้ต้องออกแรงมากขึ้นเพื่อจัดการกับโคลนจำนวนมากของเขาในขณะที่พยายามซ่อนความยุ่งเหยิงที่เขาสร้างขึ้นจากภรรยาของเขา การบรรลุความพร้อมใช้งานของการโคลนในระบบคลาวด์ด้วยผลลัพธ์ที่ดีกว่าไม่ใช่เรื่องยาก โคลนอย่างระมัดระวังเพื่อหลีกเลี่ยงการทำงานมากขึ้นและเพิ่มความเสี่ยงจากเครื่องมือที่ควรจะทำให้งานของคุณง่ายขึ้นและสภาพแวดล้อมของคุณปลอดภัยยิ่งขึ้น – Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า ผลิตซ้ำจาก SIOS |
| ธันวาคม 26, 2020 |
ผลิตภัณฑ์ใหม่: SIOS Protection Suite สำหรับ Linux 9.5.1 |
| ธันวาคม 22, 2020 |
หกเหตุผลที่การย้ายระบบคลาวด์ของคุณหยุดทำงาน |
| ธันวาคม 18, 2020 |
การคำนวณความพร้อมใช้งานของแอปพลิเคชันในคลาวด์
การคำนวณความพร้อมใช้งานของแอปพลิเคชันในคลาวด์เมื่อปรับใช้แอปพลิเคชันที่สำคัญทางธุรกิจในระบบคลาวด์คุณต้องแน่ใจว่าแอปพลิเคชันเหล่านี้พร้อมใช้งานสูง ข่าวดีก็คือหากคุณวางแผนอย่างถูกต้องคุณจะมีความพร้อมใช้งาน 99.99% (4-nines) หรือมากกว่านั้น อย่างไรก็ตามการคำนวณความพร้อมใช้งานที่แท้จริงของคุณอาจไม่ตรงไปตรงมาอย่างที่คิด เมื่อพิจารณาถึงความพร้อมใช้งานคุณต้องพิจารณาองค์ประกอบหลักที่ทำให้การเข้าถึงแอปพลิเคชันของคุณเป็นไปได้ซึ่งฉันจะเรียกว่าโซ่ความพร้อมใช้งาน ส่วนประกอบของห่วงโซ่ความพร้อมใช้งาน ได้แก่ :
แอปพลิเคชันของคุณจะพร้อมใช้งานเป็นลิงก์ที่อ่อนแอที่สุดเท่านั้นและการหยุดทำงานของคุณจะเพิ่มขึ้นเป็นทวีคูณด้วยลิงก์เพิ่มเติมแต่ละลิงก์ที่คุณเพิ่มลงในเครือข่ายลองตรวจสอบแต่ละลิงก์ ความพร้อมในการคำนวณผู้ให้บริการคลาวด์รายใหญ่สามรายแต่ละรายมีความคล้ายคลึงกันบางประการ สิ่งหนึ่งที่เหมือนกันในทั้งสามแพลตฟอร์มคือข้อตกลงระดับบริการ (SLA) ที่พวกเขาจะยอมรับในการคำนวณ SLA สำหรับผู้ให้บริการระบบคลาวด์สาธารณะทั้งสามสำหรับ VM เมื่อคุณมี VM สองรายการขึ้นไปที่กำหนดค่าในโซนความพร้อมใช้งานที่แตกต่างกันคือ 99.99%โปรดทราบว่า SLA นี้รับประกันเฉพาะการเข้าถึงระยะไกลของหนึ่งใน VMs ในช่วงเวลาใดเวลาหนึ่งโดยไม่มีสัญญาเกี่ยวกับความพร้อมใช้งานของบริการหรือแอปพลิเคชันที่ทำงานอยู่ภายใน VMหากคุณปรับใช้ VM เดียวภายในศูนย์ข้อมูลเดียว SLA นี้จะแตกต่างกันไปตั้งแต่“ 90% ของแต่ละชั่วโมง” (AWS) ถึง 99.5% (Azure และ GCP) หรือ 99.9% (Azure single VM เมื่อใช้ Premium SSD) ความพร้อมใช้งานสูงอย่างแท้จริงเริ่มต้นที่ 99.99% ดังนั้นขั้นตอนแรกคือการตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณพร้อมใช้งานคือตรวจสอบให้แน่ใจว่าแอปพลิเคชันได้รับการแจกจ่ายไปยัง VM สองเครื่องหรือมากกว่าซึ่งครอบคลุมโซนความพร้อม ด้วย VM สองตัวที่กระจายอยู่ในโซนความพร้อมใช้งานสองโซนทำให้คุณมี VM อย่างน้อยหนึ่งตัวที่พร้อมใช้งาน 99.99% คุณสามารถตั้งทฤษฎีได้ว่าหากคุณมี VM สามเครื่องที่กระจายอยู่ในโซนความพร้อมใช้งาน 3 โซนความพร้อมของคุณจะมากกว่า 99.99% แม้ว่า SLA ของผู้ให้บริการระบบคลาวด์จะไม่รับประกันความพร้อมใช้งานเกิน 99.99% โดยไม่คำนึงถึงจำนวนโซนความพร้อมใช้งานที่ใช้งาน แต่หากคุณใช้สถิติที่แท้จริงคุณอาจสรุปได้ว่าความพร้อมใช้งานของคุณอาจเพิ่มขึ้นสูงถึง 99.999999% หรือ 8-nines ของ ความพร้อมใช้งานการหยุดทำงาน 26.30 มิลลิวินาทีต่อเดือน 1 – (. 0001 * .0001) = .99999999 99.999999% พร้อม 3 โซนความพร้อม? อย่าไปอ้างตัวเลขนั้น แต่อย่าลืมว่ามันสมเหตุสมผลแล้วถ้าโซนความพร้อม 2 โซนสามารถให้คุณพร้อมใช้งานได้ 99.99% เป็นไปตามเหตุผลว่าโซนความพร้อมใช้งาน 3 แห่งจะให้ความพร้อมใช้งานมากกว่า 99.99% Compute เป็นเพียงลิงก์เดียวในห่วงโซ่ความพร้อมใช้งาน เรายังคงต้องจัดการกับเครือข่ายพื้นที่จัดเก็บข้อมูลและบริการอื่น ๆ ที่ต้องพึ่งพาซึ่งทั้งหมดนี้แสดงถึงจุดที่เป็นไปได้ของความล้มเหลว ความพร้อมใช้งานของเครือข่ายเพื่อให้แอปพลิเคชันของคุณพร้อมใช้งานเครือข่ายทุกเครือข่ายระหว่างไคลเอนต์และแอปพลิเคชันและทรัพยากรทั้งหมดที่แอปพลิเคชันขึ้นอยู่จะต้องพร้อมใช้งานและทำงานในช่วงเวลาแฝงที่ยอมรับได้ คุณต้องเข้าใจการเชื่อมโยงเครือข่ายระหว่างเซิร์ฟเวอร์ฐานข้อมูลแอ็พพลิเคชันเซิร์ฟเวอร์เว็บเซิร์ฟเวอร์และไคลเอ็นต์เพื่อให้ทราบอย่างแม่นยำว่าเครือข่ายอาจล้มเหลวที่ใด โปรดจำไว้ว่ายิ่งลิงก์ในห่วงโซ่ความพร้อมใช้งานของคุณมีความพร้อมใช้งานโดยรวมลดลง แม้ว่าความพร้อมใช้งานของเครือข่ายระหว่าง VM ใน vNet เดียวกันจะครอบคลุมภายใต้ SLA การประมวลผลมาตรฐาน แต่ก็มีบริการเครือข่ายอื่น ๆ ที่คุณอาจใช้ นี่เป็นเพียงตัวอย่างบางส่วนของบริการเครือข่ายที่คุณสามารถใช้ได้ซึ่งจะส่งผลต่อความพร้อมใช้งานของแอปพลิเคชันโดยรวม เส้นทางด่วน – 99.95% จากสิ่งที่เราได้เรียนรู้ไปแล้วเรามาดูความพร้อมใช้งานของแอปพลิเคชันที่ใช้งานได้ในสองโซนความพร้อมใช้งาน ความพร้อมในการประมวลผล 99.99% ความพร้อมใช้งานของตัวจัดสรรภาระงาน 99.99% .9999 * .9999 = .9998 ความพร้อมใช้งาน 99.98% = การหยุดทำงานประมาณ 9 นาทีต่อเดือน ตอนนี้เราได้จัดการกับความพร้อมในการประมวลผลและเครือข่ายแล้วเรามาดูพื้นที่เก็บข้อมูลกัน ความพร้อมในการจัดเก็บตอนนี้ที่นี่เป็นที่ที่เรื่องราวมีขนเล็กน้อย ดู SLA หน่วยเก็บข้อมูลต่อไปนี้ https://azure.microsoft.com/en-us/support/legal/sla/storage/v1_5/ https://cloud.google.com/storage/sla https://aws.amazon.com/compute/sla/ ดูเหมือนชัดเจนว่า Azure และ Google กำลังให้ SLA 99.9% สำหรับโซลูชันการจัดเก็บบล็อก AWS ไม่ได้กล่าวถึง EBS โดยเฉพาะที่นี่ พวกเขาพูดถึง VM และวัดความพร้อมใช้งาน VM ของอินสแตนซ์เดียวเป็นรายชั่วโมงแทนที่จะเป็นรายเดือนเหมือนที่ผู้ให้บริการคลาวด์รายอื่นทำ เพื่อประโยชน์ในการสนทนาให้ใช้การรับประกันความพร้อมใช้งาน 99.9% ที่ทั้ง Azure และ GCP ได้เผยแพร่ จากตัวอย่างก่อนหน้านี้เรามาเพิ่มพื้นที่เก็บข้อมูลให้กับสมการกัน ความพร้อมในการประมวลผล 99.99% ความพร้อมใช้งานของตัวจัดสรรภาระงาน 99.99% ดิสก์ที่มีการจัดการ 99.9% .9999 * .9999 * .999 = .9988 ความพร้อมใช้งาน 99.88% = ~ 53 นาทีของการหยุดทำงานต่อเดือน การหยุดทำงาน 53 นาทีนั้นมากกว่าเวลาหยุดทำงาน 9 นาทีที่เราคำนวณไว้ในตัวอย่างก่อนหน้านี้มาก เราจะทำอย่างไรเพื่อลดผลกระทบจากความพร้อมใช้งานของพื้นที่จัดเก็บ 99.9% เราต้องสร้างความซ้ำซ้อนในการจัดเก็บมากขึ้น! โชคดีที่เรามักจะรวมความซ้ำซ้อนของพื้นที่เก็บข้อมูลไว้ด้วยเมื่อวางแผนสำหรับความพร้อมใช้งานของแอปพลิเคชัน ตัวอย่างเช่นเมื่อเราตั้งค่าเว็บเซิร์ฟเวอร์โดยทั่วไปเว็บเซิร์ฟเวอร์แต่ละแห่งจะจัดเก็บข้อมูลไว้ในดิสก์ที่เชื่อมต่อภายในเครื่อง เมื่อปรับใช้ตัวควบคุมโดเมน Microsoft Active Directory จะดูแลการจำลองข้อมูล AD ในตัวควบคุมโดเมนทั้งหมด ในกรณีของบางอย่างเช่น SQL Server เราใช้ประโยชน์จากสิ่งต่างๆ Always On Availability Groups หรือ SIOS DataKeeper เพื่อให้ข้อมูลซิงค์กับดิสก์ที่เชื่อมต่อภายในเครื่อง ยิ่งเราแจกจ่ายสำเนาข้อมูลในโซนความพร้อมใช้งานต่างๆมากเท่าไหร่เราก็จะมีโอกาสรอดจากความล้มเหลวได้มากขึ้นเท่านั้น ตัวอย่างเช่นแอปพลิเคชันที่จัดเก็บข้อมูลในดิสก์สองแผ่นในโซนความพร้อมใช้งานที่แตกต่างกันจะได้รับประโยชน์จากความซ้ำซ้อนและแทนที่จะมีความพร้อมใช้งาน 99.9% มีแนวโน้มที่จะมีพื้นที่จัดเก็บถึง 99.9999% 1 – (.001 * .001) = .999999 ถ้าเราใส่มันลงในสมการก่อนหน้านี้รูปภาพจะดูสว่างขึ้นเล็กน้อย .9999 * .9999 * .999999 = .9998 ความพร้อมใช้งาน 99.98% = ~ 9 นาทีของการหยุดทำงาน ด้วยการทำซ้ำข้อมูลในหลาย AZ และหลายดิสก์เราจึงลดเวลาหยุดทำงานที่เกี่ยวข้องกับที่เก็บข้อมูลบนคลาวด์ได้อย่างมีประสิทธิภาพ ความพร้อมใช้งานของแอปพลิเคชันและบริการที่ต้องพึ่งพาคุณได้ทำทุกอย่างที่ทำได้เพื่อให้แน่ใจว่ามีการประมวลผลเครือข่ายและพื้นที่เก็บข้อมูล แต่ตัวแอปพลิเคชันล่ะ? แอปพลิเคชันบางตัวสามารถขยายขนาดและจัดเตรียมความซ้ำซ้อนได้โดยการทำโหลดบาลานซ์ระหว่างอินสแตนซ์หลายรายการของแอปพลิเคชันเดียวกัน ลองนึกถึงฟาร์มเว็บเซิร์ฟเวอร์ทั่วไปของคุณที่โดยทั่วไปคุณอาจโหลดคำขอเว็บสมดุลระหว่างเซิร์ฟเวอร์ห้าเครื่อง หากคุณสูญเสียเซิร์ฟเวอร์หนึ่งตัวตัวโหลดบาลานเซอร์จะลบเซิร์ฟเวอร์ออกจากการหมุนเวียนจนกว่าจะมีการตอบสนองอีกครั้ง แอปพลิเคชันอื่น ๆ ต้องการการดูแลและตรวจสอบมากกว่านี้เล็กน้อย ใช้ SQL Server เป็นต้น โดยปกติ Always On Availability Groups หรือ Failover Cluster Instances จะใช้เพื่อตรวจสอบความพร้อมใช้งานของฐานข้อมูลและดำเนินการกู้คืนหากฐานข้อมูลไม่ตอบสนองเนื่องจากความล้มเหลวของแอปพลิเคชันหรือระดับระบบ แม้ว่าจะไม่มี SLA ที่เผยแพร่สำหรับโซลูชันความพร้อมใช้งานของ SQL Server แต่เป็นที่ยอมรับกันโดยทั่วไปว่าเมื่อกำหนดค่าอย่างเหมาะสมเพื่อความพร้อมใช้งานสูง SQL Server สามารถให้ความพร้อมใช้งานได้ 99.99% คุณอาจพึ่งพาบริการบนคลาวด์อื่น ๆ เช่น Active Directory โฮสต์ DNS ที่โฮสต์ไมโครเซอร์วิสหรือแม้แต่ความพร้อมใช้งานของพอร์ทัลระบบคลาวด์เองทั้งหมดควรรวมอยู่ในสมการความพร้อมใช้งานโดยรวมของคุณ สรุปความพร้อมใช้งานคือผลรวมของชิ้นส่วนที่เคลื่อนไหวทั้งหมด การข้ามไปในพื้นที่เดียวอาจส่งผลต่อความพร้อมใช้งานโดยรวมของแอปพลิเคชันของคุณอย่างทวีคูณ ใช้เวลาของคุณและตรวจสอบลิงก์ทั้งหมดในห่วงโซ่ความพร้อมใช้งานของคุณเพื่อหาจุดอ่อนรวมถึงการประมวลผลเครือข่ายพื้นที่เก็บข้อมูลแอปพลิเคชันและบริการที่ต้องพึ่งพา โดยทั่วไปแล้วตัวเลขที่นำเสนอนี้หวังว่าจะเป็นสถานการณ์ในกรณีที่เลวร้ายที่สุดและความพร้อมใช้งานจริงของคุณควรเกิน SLA ที่เผยแพร่ ทำการบ้านและระวังบริการใด ๆ ที่ไม่สามารถรับประกันความพร้อมใช้งาน 99.99% ซึ่งเป็นเกณฑ์ทั่วไปของสิ่งที่ถือว่าพร้อมใช้งานสูง ข้อผิดพลาดของมนุษย์และความปลอดภัยไม่ได้รับการแก้ไขในบทความนี้ คุณสามารถทำให้แอปพลิเคชันของคุณพร้อมใช้งานมากที่สุด อย่างไรก็ตามหากคุณไม่ได้ทำตามขั้นตอนเพื่อรักษาความปลอดภัยให้กับแอปพลิเคชันของคุณจากภัยคุกคามภายนอกและความผิดพลาดที่โง่เขลาของมนุษย์การเดิมพันทั้งหมดจะถูกปิดเมื่อถึงเวลาที่ว่าง |
