One place for hosting & domains

      Redundancy

      Deploying MongoDB With Redundancy



      Part of the Series:
      MongoDB Security: Best Practices to Keep Your Data Safe

      MongoDB, also known as Mongo, is a document database used in many modern web applications. As with any database management system, it’s critical that those responsible for managing a Mongo database adhere to the recommended security best practices, both to prevent data from being lost in the event of a disaster and to keep it out of the hands of malicious actors.

      This series of conceptual articles provides a high-level overview of MongoDB’s built-in security features while also highlighting some general database security best practices.

      No matter what precautions you or your cloud provider take to prevent them, computers are always at risk of hardware failure. An important part of managing any computer system, not just a MongoDB installation, is to make regular backups of your important information. By taking and storing backups of your data, you can restore your application to working order if your database server crashes and your original data is lost.

      Just as you should regularly back up your MongoDB data, it’s equally important that you store those backups in a separate location from the server hosting your database. If you were to store your backups in the same data center as your database, both the database and your backups would be unavailable if the data center were to experience a failure and you wouldn’t be able to use the backups to get your application back online.

      Replication is a practice that’s similar to making backups: where making a backup involves taking a point-in-time snapshot of all the data held in a database, replication involves constantly synchronizing data across multiple separate databases. It’s often useful to have multiple replicas of your data, as this provides redundancy in case one of the database servers fails and can also improve a database’s availability and scalability, as well as reduce read latencies. In MongoDB, a group of servers that maintain the same data set through replication are referred to as a replica set.

      The official documentation recommends that any Mongo database used in a production environment be deployed as a replica set, since MongoDB replica sets employ a feature known as automatic failover. This means that if the primary fails and is unable to communicate with the secondary members for a predetermined amount of time, the secondary members will automatically elect a new primary member, thereby ensuring that your data remains available to your application or the clients that depend on it.



      Source link

      Network Redundancy vs. Network Diversity: What’s the Difference, and Do I Need Both?


      Network redundancy is a duplicated infrastructure where additional or alternate instances of network devices and connections are installed to ensure an alternate path in case of a failure on the primary service. This is how you keep your business online and available should your main path of communication go down.

      While redundancy is great, many times services are in the same data center, share the same fiber bundle, patch panel or equipment. In fact, hardware failures and fiber cuts are the leading causes of network outages today.

      Being redundant may not protect you as well as planned.

      Network Redundancy vs. Network Diversity

      A duplicate or alternate instance of your network doesn’t always protect you from the leading causes of network outages, and it can’t always protect you from less frequent, but more catastrophic incidents, like floods or fires. Sometimes construction work, human error and even squirrels can interrupt your network service. To protect against these scenarios, network diversity is the answer.

      Network diversity takes redundancy one step further, duplicating your infrastructure on a geographically diverse path, in another data center or even in the cloud.

      Achieving Network Diversity Through Geographic Redundancy

      Diversity is key. Being geographically diverse protects you from weather events, construction and other single location incidents. If your redundant site is in a different state, or even in another country, your chances of two impacting events at the same time are significantly lessened. For even greater resiliency, you can move your redundancy or disaster recovery to the cloud via a Disaster Recovery as a Service solution.

      Achieving Network Diversity via Multihomed BGP

      You can achieve network diversity by being in geographically diverse data centers with the use of multihomed BGP. INAP offers the use of several BGP communities to ensure immediate failover of routing to your data center environment in case of a failure. Additionally, through INAP’s propriety technology, Performance IP®, your outbound traffic is automatically put on the best-performing route.

      Achieving Network Diversity Through Interconnection

      Another consideration is the connection from the data center to your central office. One can assume just because you have two different last mile providers for your redundancy that they use different paths. This usually is not the case; many fiber vaults and manholes are shared. This can result in both your primary and back up service being impaired when a backhoe unearths an 800-strand fiber. Ask the provider to share the circuit path to ensure your services are on diverse paths. INAP works to avoid these issues by offering high capacity metro network rings in key markets. Metro Connect interconnects multiple data centers with diverse paths, allowing you to avoid single points of failure for your egress traffic.

      Conclusion

      Redundancy is key to maintain the demanding uptime of today’s business. In most cases this does the job, however if your model is 100 percent uptime, it may be beneficial to start investing in a diverse infrastructure, as well.

      Explore INAP’s Global Network.

      LEARN MORE

      Erik Irwin
      • Director, Advanced Services, Global Network Services


      READ MORE



      Source link